Editing Talk:Diablo Extras repository proposal

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

== Issues for on-device developers ==
If i understand well, only package build with autobuilder could be uploaded. If it s the case, i don't think it s a good solution for onboard developpers, as debian tool can't be used directly on the it. If diablo let s us use debian packaging tool directly on tablet it ll not be a problem. (The main problem using dpkg-buildpackage is that many option of many tools aren't available due to busybox).

Furthermore, if there is too difficulty to upload to extras or extras-devel, many dev will make their own repository. And i don't think it s a good idea. But i understand that you want to have a repository were users can rely on and where there is no error on installing packages.--[[User:khertan|khertan]] 11:08, 19 June 2008 (GMT+2)
: I think that your specific problem is mainly for python developers, only developing on the tablet itself. Easiest solution for them would be to improve pypackager so it creates valid archives and can upload the packages. As I understand it is almost doing that already and just might need a few fixes. Sure it would require a little more effort from developers, but they also have an interest in getting their applications to the end user? --[[User:xfade|xfade]] 09:24, 19 June 2008 (UTC)
:: I agree, this is just why i ven't say anything for freemantle, just to get the time to fix pypackager to make clean packages for diablo. And i hope developpers will not create others repositories.--[[User:khertan|khertan]] 17:04, 19 June 2008 (GMT+2)

== Section problem ==
Please let us fix the section problem. Packages to go into extras and extras-devel must respect the naming scheme for sections. This was often critized and (while there is possibly no solution yet) this would be the right time to get it solved. --[[User:framstag|framstag]] 12:01, 19 June 2008 (UTC)
: This section problem is something we can't easily fix and certainly not on a short-term. There will always be a category that isn't described in our 'official' sections list. Debtags really seems to be a better solution, but it would need to be implemented in the Application Manager too. Aim for Fremantle to get debtags introduced? --[[User:xfade|xfade]] 14:43, 19 June 2008 (UTC)
::On the debtags note, has anybody opened an enhancement request for that yet? —[[User:generalantilles|GeneralAntilles]] 15:11, 19 June 2008 (UTC)
::While you are right that we cannot solve this completely we could at leats clean up the situation. That means define standard groups most packages have to use and define exceptions where it makes sence (application that consist of a huge number of packages or that do not fit any other group). We should be pragmatic in the sence that we do not need a perfect solution and we should not start a flame war, but at little clean up should be possible. In consequence we generate a nice knowledge base for later discussions regarding debtags. Note however that personally I do not think that debtags will solve the problem (not enough overview), it is not the perfect solution and might be generate problesm of its own if not used with care, the same care one would need for good section names. --[[User:framstag|framstag]] 15:07, 20 June 2008 (UTC)

== Binary-only packages? ==
I agree with the proposal, but what about binary only packages ?
--[[User:anidel|anidel]] 13:59, 19 June 2008 (UTC)
:Do you mean closed source applications? Or for example an icon pack? --[[User:xfade|xfade]] 14:45, 19 June 2008 (UTC)
::Canola would be the obvious example. --[[User:jaffa|Jaffa]] 22:27, 20 June 2008 (UTC)
:Of course, a "source" package is just a package which can be extracted, a particular command run and a binary deb produced. There's nothing stopping closed source authors such as INDT producing a "source" package containing the binary files and a script to produce the binary deb. This'd satisfy the "only packages which can be built using the autobuilder" requirement ''and'' add an extra level of complexity to people wanting to use the maemo.org '''community''' repository for their closed source applications. --[[User:jaffa|Jaffa]] 18:59, 21 June 2008 (UTC)
::As a note aside, should we discusse now the possibility of having free & non-free sections (or universe / multiverse) for these 3rd party repository that today we call extras? I mean, imagine that one day Nokia packages are published as i.e. Main / Restricted. Is this on topic here?--[[User:qgil|qgil]] 19:11, 22 June 2008 (UTC)
::I think the free/non-free thing would be a good solution. But for the community repository, surely we should aim to have as much source available as possible. --[[User:xfade|xfade]] 10:10, 23 June 2008 (UTC)
:::Wherever possible, I'm in favour of copying best practice. If it's good enough for Ubuntu to copy (and tweak) from Debian, it should be possible for us to copy from Ubuntu (and tweak). Having said that, until diablo's released (I put off installing the unreleased version), I think SSU is too much of a wildcard to make ''many'' decisions now. Are there any plans on Nokia's side as to the frequency of a release's in-life updates? Feature enhancements? Bug fixes? Security fixes? Or will SSU solely be used for big bang releases without having to reflash? --[[User:jaffa|Jaffa]] 19:21, 22 June 2008 (UTC)
::::What is the relation between having separate sections for free/non-free and frequency of updates? In any case I'm thinking more about the Fremantle timeline since Diablo is too soon to implement radical changes.--[[User:qgil|qgil]] 19:38, 22 June 2008 (UTC)
::::This SSU thing is an entirely different thing and is not being served from the extras repository. As I understand it is for ''system'' updates (applications part of the base system, not for ''application'' updates (community provided applications). --[[User:xfade|xfade]] 10:10, 23 June 2008 (UTC)
:::::I still fail to see what is the relation between SSU and free/non-free, but I just thorught youd like to know that yes, users get SSU updates when new versions of their installed extras software are available.--[[User:qgil|qgil]] 11:00, 23 June 2008 (UTC)
:::::If the frequency of updates is on the same order of magnitude of current "maemo Linux based OS" releases (i.e. a couple a year), carefully crafting the naming seems to me to be a monumental waste of effort. However, if a) there's going to be lots and lots and some careful differentiation is required; or there'll be many more Nokia self-installable apps released (or other, non-free apps in addition to the couple we've got already); the distinction may be worth investing in. Alternatively, I've got the wrong end of the stick. --[[User:jaffa|Jaffa]] 19:43, 22 June 2008 (UTC)
::::::Alright, let me rephrase my own question above: would it make sense to differentiate free and non-free extras packages in different sections? (the discussion about Nokia packages is not urgent and belongs to somewhere else)--[[User:qgil|qgil]] 19:56, 22 June 2008 (UTC)
:::::::From the user's point of view? Probably not. From a community point of view? Not sure. From Nokia's point-of-view? I'm not in a position to answer, but is it likely/possible that at some point extras (in some form) will be enabled by default? If so, does a free/non-free separation have any bearing on it? --[[User:jaffa|Jaffa]] 20:05, 22 June 2008 (UTC)

== Please, Keep Original Submission Procedure for Binary Packages ==
I strongly suggest that you keep the original dput-based submission procedure for binary packages, possibly marking them as non-free. The suggested submission procedure with autobuilder + promotion (1) requires the source code (not available for closed source packages) and (2) takes much more time than just doing a "dput", complicating frequent package updates. This force developers to ignore Extras repository and either create their own repositories or not use repository model at all. While centering submission process around the source code has valiant open-source intentions, it basically limits developers' freedom to distribute their software however they want. Any barriers to package submission (however idealistic their reasons are) will harm end users who expect most NIT software to be available from a single repository. [[User:fms|fms]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Talk:Diablo_Extras_repository_proposal"

Latest revision		Your text
Line 29:		Line 29:

	== Please, Keep Original Submission Procedure for Binary Packages ==		== Please, Keep Original Submission Procedure for Binary Packages ==
-	I strongly suggest that you keep the original dput-based submission procedure for binary packages, possibly marking them as non-free. The suggested submission procedure with autobuilder + promotion (1) requires the source code (not available for closed source packages) and (2) takes much more time than just doing a "dput", complicating frequent package updates. This ~~forces~~ developers to ignore Extras repository and either create their own repositories or not use repository model at all. While centering submission process around the source code has valiant open-source intentions, it basically limits developers' freedom to distribute their software ~~via centralized Extras repository~~. Any barriers to package submission (however idealistic their reasons are) will harm end users who expect most NIT software to be available from a single repository. [[User:fms\|fms]]	+	I strongly suggest that you keep the original dput-based submission procedure for binary packages, possibly marking them as non-free. The suggested submission procedure with autobuilder + promotion (1) requires the source code (not available for closed source packages) and (2) takes much more time than just doing a "dput", complicating frequent package updates. This force developers to ignore Extras repository and either create their own repositories or not use repository model at all. While centering submission process around the source code has valiant open-source intentions, it basically limits developers' freedom to distribute their software however they want. Any barriers to package submission (however idealistic their reasons are) will harm end users who expect most NIT software to be available from a single repository. [[User:fms\|fms]]

Personal tools

Navigation

Views

Editing Talk:Diablo Extras repository proposal