• Intro
• Downloads
• Community
• Development
• News
• TALK

Talk:Diablo Extras repository proposal

[edit] 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.--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? --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.--khertan 17:04, 19 June 2008 (GMT+2)

[edit] 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. --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? --xfade 14:43, 19 June 2008 (UTC)

On the debtags note, has anybody opened an enhancement request for that yet? —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. --framstag 15:07, 20 June 2008 (UTC)

[edit] Binary-only packages?

I agree with the proposal, but what about binary only packages ? --anidel 13:59, 19 June 2008 (UTC)

Do you mean closed source applications? Or for example an icon pack? --xfade 14:45, 19 June 2008 (UTC)

Canola would be the obvious example. --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. --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?--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. --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? --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.--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). --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.--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. --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)--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? --Jaffa 20:05, 22 June 2008 (UTC)

[edit] 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. fms