Re: policy: maemo packaging policy -draft
Hi, Allen Brown wrote: * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. Speaking as a user, the *lack* of asking which menu this belongs under is annoying. Stuffing all add-ons into Extras sucks. I want my tools organized according to uses, not according to which person developed them. Personally, I would vastly prefer a system like .desktop files where the developer says what categories the application is in, and it gets placed in the relevant menu(s). I don't like having to enter a menu name for, say, a game, when it should obviously go in the (non-existent) Games menu. Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Dnia Sunday 08 of June 2008, Allen Brown napisał: * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. Speaking as a user, the *lack* of asking which menu this belongs under is annoying. Stuffing all add-ons into Extras sucks. I want my tools organized according to uses, not according to which person developed them. control panel allows You to organize this menu in any way you want. With crap called Application Manager where you can install just one application at time asking used is 'acceptable' but when I install packages using apt-get it is really annoying to check why does installing halted which happens when apt-get is called from remote shell and application asks where do I want to have it. With those 'finger-but-not-user friendy' style menus putting everyting into Extras has sense. -- JID: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi, ext Marius Gedminas wrote: On Wed, May 28, 2008 at 10:32:22AM +0300, Eero Tamminen wrote: A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf If you're packaging software for maemo, please take a look at it. * Testing on a device with no extra packages is a hard to do, unless you have two devices, or you're not actually using the one you have. Maybe this would be better: As a result, package installation and uninstallation MUST be tested (also) on the device, before the package is uploaded to the repositories. Test device SHOULD NOT have extra software installed. I wish we had a complete hardware emulator so that you could test package installation on a pristine rootfs in a virtual machine. Qemu got recently some preliminary N8x0 support: http://svn.savannah.gnu.org/viewvc/trunk/Changelog?revision=4490root=qemuview=markup I haven't tried it myself. In theory the better package dependency / Busybox testing should be possible on Desktop x86 too, but there's no ready made maemo x86 image that one could boot in x86 system Qemu. * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. Along with selecting sensible defaults so that if/when the GUI tools will support non-interactive mode like the Debian tools do, the package wouldn't do anything stupid. Debconf support is not currently planned though. * Splitting translations has a question about Debian/Ubuntu. I'm not a developer of either, but as far as I know Debian ships translation files for all languages in the same .deb that contains the software, Which has the drawback that translations are tied to the software updates... while Ubuntu collects all translations from a big group of related packages into a language-pack-$group-$languagecode, so you end up with language-pack-lt, language-pack-gnome-lt, language-pack-kde-lt and so on. Which at least earlier had the drawback of forcing Thunderbird, Firefox and OpenOffice installation on Kubuntu... The Ubuntu solution is only possible because they release the whole stack at once. As stated in the policy document, the comments and questions on this policy should be mailed to the maemo-developers mailing list with word policy in the subject. This thread qualifies. ;-) Sure. :-) Thanks for the feedback! - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Yes, that is why I have created several new menus. Once that actually make a little sense. It is then easy to select them instead of Extras. -- Allen Brown http://brown.armoredpenguin.com/~abrown Hi, Allen Brown wrote: * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. Speaking as a user, the *lack* of asking which menu this belongs under is annoying. Stuffing all add-ons into Extras sucks. I want my tools organized according to uses, not according to which person developed them. Personally, I would vastly prefer a system like .desktop files where the developer says what categories the application is in, and it gets placed in the relevant menu(s). I don't like having to enter a menu name for, say, a game, when it should obviously go in the (non-existent) Games menu. Cheers, Dave. -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
* Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. Speaking as a user, the *lack* of asking which menu this belongs under is annoying. Stuffing all add-ons into Extras sucks. I want my tools organized according to uses, not according to which person developed them. -- Allen Brown abrown at peak.org http://brown.armoredpenguin.com/~abrown/ I have noticed that the people who are late are often so much jollier than the people who have to wait for them. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi! On Wed, May 28, 2008 at 10:32:22AM +0300, Eero Tamminen wrote: A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf If you're packaging software for maemo, please take a look at it. * Testing on a device with no extra packages is a hard to do, unless you have two devices, or you're not actually using the one you have. I wish we had a complete hardware emulator so that you could test package installation on a pristine rootfs in a virtual machine. * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. * Splitting translations has a question about Debian/Ubuntu. I'm not a developer of either, but as far as I know Debian ships translation files for all languages in the same .deb that contains the software, while Ubuntu collects all translations from a big group of related packages into a language-pack-$group-$languagecode, so you end up with language-pack-lt, language-pack-gnome-lt, language-pack-kde-lt and so on. The Ubuntu solution is only possible because they release the whole stack at once. As stated in the policy document, the comments and questions on this policy should be mailed to the maemo-developers mailing list with word policy in the subject. This thread qualifies. ;-) Marius Gedminas -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi, ext Graham Cobb wrote: On Wednesday 28 May 2008 08:32:22 Eero Tamminen wrote: A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf Let me start by saying thanks for a useful and well-written document. I am not quite sure about the name: personally I am not convinced that we need a strict policy for Maemo packages. I completely agree we need guidelines but Maemo is a small (really, tiny) distribution, both in terms of users and, more importantly for this discussion, developers. Our most critical problem at the moment is the lack of ported software, not the quality of the packages which have been ported. This policy is supposed to concern also developers inside Nokia (although there are still our own packages that don't quite conform to it), not just outside. That's the reason for some of the things in the policy. We hope that same policy can apply to both. If anything, the number of active developers in the Maemo community seems to be declining (for example, I was amazed by the almost zero response to the autobuilder announcement). I would be very firmly against any attempt to enforce a policy (for example, by preventing packages appearing in Extras if they violate the policy). But, I realise that that is a separate discussion. My comments below do assume that this is an advisory policy (or guidelines as I would prefer to call it). Currently policy doesn't have that many hard rules and whether maemo community wants some of them to be enforced for some of the repositories is for community to decide I think. Internally we will have some checks for packages, but I think the main point of policy is as reference/guideline about how things should be done. Basically it means that if packaging doesn't conform to policy, you're allowed to complain. :-) Then it has alternatives on how that situation should be handled: change package, propagate change to upstream, change policy or explain and document the reason for difference. 2.2: The list of user sections should not be in this document. It should be on a Wiki page which can be maintained separately from the document. The current policy is modeled after Debian policy which lists the package sections in the policy: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections Because the document relies so much on the Debian policy, splitting the content differently from that would make the document much harder to read and correlate to the upstream policy. Anyway, how often the package sections are going to change anyway? For now I expect policy to get some updates in each new major maemo release and the packaging sections can be updated at the same time. 3.2: This section needs to be clearer about the circumstances which cause the maemo version string to be required. If a Debian package is taken and the only changes are to the debian/control file (e.g. Section: changed to conform to 2.2, dependencies changed to reflect maemo environment differences, maintainer changed, etc.) then I would have thought it should retain the debian version number. On the other hand, if a source or build change occurs (for example, a feature which is enabled in the Debian version is disabled in the maemo version because it makes no sense in that environment, or is dependent on something which has not been ported) then the maemo revision should be used. Other changes may be less clear (for example, if the documentation has been removed as per 3.9.4). As already explained in earlier reply, any change needs a new version. 3.9: I don't really see the point in saying packaging changes SHOULD be propagated back to upstream. No Debian maintainer is going to change any of their packaging for the benefit of Maemo! Are you really suggesting people should report bugs on a maemo package because the upstream maintainer chooses to package it differently?! Why not? There should be at least *some* reason for diverging from upstream. The reasons for this should be clear, so that the next person taking a newer version from upstream knows whether to apply similar changes. 3.9.4. Remove the line about generating API documentation from sources. While I agree that is good software engineering practice, it is not a packaging issue and doesn't belong in this document. Agree. The footnote about documentation could be changed to: Generating the API documentation from source is strongly recommended. The preferred tools for this are gtk-doc and doxygen. 3.9.5. I agree with this section as currently written. It must not become MUST as it is really only critical for general purpose libraries and general purpose plugin based applications. Some applications may use libraries and plugins which are only for the convenience of the application developers and are not, realistically, ever going to
Re: policy: maemo packaging policy -draft
ext Guillem Jover wrote: Porting software should not be needed most of the time, and maemo would be better off pulling directly from the Debian armel archives. This is a separate discussion, but it would be good to go through specific cases of different packages in Debian and Ubuntu and see why the diff. If there is no good reason then it's a bug. If there is a good reason then perhaps Debian would be interested of getting the diff. Again, the whole exercise doesn't fall only in Nokia's responsibility and the community could help if there is really an interest. And honestly the packaging I've seen in general in Maemo is not that good, not only the stuff from extras and similar, this also applies to the one from Nokia. At least now there is a reference. If someone doesn't follow it there is a measure to file a bug, no matter who is this someone. About the rest, thanks Guillem for helping out with the packaging policy! -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
On Wednesday 28 May 2008 08:32:22 Eero Tamminen wrote: A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf Let me start by saying thanks for a useful and well-written document. I am not quite sure about the name: personally I am not convinced that we need a strict policy for Maemo packages. I completely agree we need guidelines but Maemo is a small (really, tiny) distribution, both in terms of users and, more importantly for this discussion, developers. Our most critical problem at the moment is the lack of ported software, not the quality of the packages which have been ported. If anything, the number of active developers in the Maemo community seems to be declining (for example, I was amazed by the almost zero response to the autobuilder announcement). I would be very firmly against any attempt to enforce a policy (for example, by preventing packages appearing in Extras if they violate the policy). But, I realise that that is a separate discussion. My comments below do assume that this is an advisory policy (or guidelines as I would prefer to call it). 2.2: The list of user sections should not be in this document. It should be on a Wiki page which can be maintained separately from the document. 3.2: This section needs to be clearer about the circumstances which cause the maemo version string to be required. If a Debian package is taken and the only changes are to the debian/control file (e.g. Section: changed to conform to 2.2, dependencies changed to reflect maemo environment differences, maintainer changed, etc.) then I would have thought it should retain the debian version number. On the other hand, if a source or build change occurs (for example, a feature which is enabled in the Debian version is disabled in the maemo version because it makes no sense in that environment, or is dependent on something which has not been ported) then the maemo revision should be used. Other changes may be less clear (for example, if the documentation has been removed as per 3.9.4). 3.9: I don't really see the point in saying packaging changes SHOULD be propagated back to upstream. No Debian maintainer is going to change any of their packaging for the benefit of Maemo! Are you really suggesting people should report bugs on a maemo package because the upstream maintainer chooses to package it differently?! 3.9.4. Remove the line about generating API documentation from sources. While I agree that is good software engineering practice, it is not a packaging issue and doesn't belong in this document. 3.9.5. I agree with this section as currently written. It must not become MUST as it is really only critical for general purpose libraries and general purpose plugin based applications. Some applications may use libraries and plugins which are only for the convenience of the application developers and are not, realistically, ever going to be used by anyone else -- in those cases SHOULD would be correct. 10.4: I would change the backup SHOULD to a MUST. 11.1: You might want to add a TODO to consider adding additional future requirements on security for daemons which provide network accessible services. As this device is designed for almost continuous network connectivity, often in insecure environments, with no firewall on the device or between it and the Internet network security requirements may be stronger than for a normal Debian system. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
On Mon, 2008-06-02 at 12:15:05 +0100, ext Graham Cobb wrote: On Wednesday 28 May 2008 08:32:22 Eero Tamminen wrote: A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf I am not quite sure about the name: personally I am not convinced that we need a strict policy for Maemo packages. I completely agree we need guidelines but Maemo is a small (really, tiny) distribution, both in terms of users and, more importantly for this discussion, developers. Our most critical problem at the moment is the lack of ported software, not the quality of the packages which have been ported. If anything, the number of active developers in the Maemo community seems to be declining (for example, I was amazed by the almost zero response to the autobuilder announcement). Porting software should not be needed most of the time, and maemo would be better off pulling directly from the Debian armel archives. And honestly the packaging I've seen in general in Maemo is not that good, not only the stuff from extras and similar, this also applies to the one from Nokia. About the autobuilder, I still don't understand the need to reinvent the wheel, there's already infrastructure for that in Debian, but oh well. I would be very firmly against any attempt to enforce a policy (for example, by preventing packages appearing in Extras if they violate the policy). But, I realise that that is a separate discussion. My comments below do assume that this is an advisory policy (or guidelines as I would prefer to call it). For really broken stuff I don't see what'd be wrong in not accepting packages in the archives. I tend to agree thought that really strict enforcing (like rejecting due to warnings or not really critical stuff) at archive tool level is not generally good, as most of the time it just makes development slower, but at the same time if the policy is not followed (eventually) then there's not much point in having one. Ideally the real enforcement would be done on the release side, so packages that do not conform to all MUSTs would not get into the next Maemo release. 2.2: The list of user sections should not be in this document. It should be on a Wiki page which can be maintained separately from the document. This has been discussed before at length, but I think you guys want just debtags. 3.2: This section needs to be clearer about the circumstances which cause the maemo version string to be required. If a Debian package is taken and the only changes are to the debian/control file (e.g. Section: changed to conform to 2.2, dependencies changed to reflect maemo environment differences, maintainer changed, etc.) then I would have thought it should retain the debian version number. On the other hand, if a source or build change occurs (for example, a feature which is enabled in the Debian version is disabled in the maemo version because it makes no sense in that environment, or is dependent on something which has not been ported) then the maemo revision should be used. Other changes may be less clear (for example, if the documentation has been removed as per 3.9.4). Any change needs a new version, always, it does not matter the size of the change. It's really not good to modify something and not increment the version. Consider that in Debian even a rebuild (no changes at all) of the same package, gets a new version number (+bN). 3.9: I don't really see the point in saying packaging changes SHOULD be propagated back to upstream. No Debian maintainer is going to change any of their packaging for the benefit of Maemo! Are you really suggesting people should report bugs on a maemo package because the upstream maintainer chooses to package it differently?! No, people should report Maemo packaging problems in Maemo, but the Maemo maintainer for a given package, should send patches upstream to avoid divergence, of course not all changes are good or generic enough for upstream, but the idea would be to reduce those to a minium, or make them general enough so that they can be pushed. You'd be surprised how many DDs/DMs would take clean and sane packaging patches, that can benefit embedded systems. Another thing is if people here start messing with stuff like switching packaging from debhelper to cdbs, etc, and that'd be unacceptable. 3.9.5. I agree with this section as currently written. It must not become MUST as it is really only critical for general purpose libraries and general purpose plugin based applications. Some applications may use libraries and plugins which are only for the convenience of the application developers and are not, realistically, ever going to be used by anyone else -- in those cases SHOULD would be correct. I guess that makes sense, but only if those shared libraries or plugins do not have public interfaces, like a libfoo-dev package.
policy: maemo packaging policy -draft
Hi, A draft version of the maemo packaging policy is available for commenting: https://maemo.org/forrest-images/pdf/maemo-policy.pdf If you're packaging software for maemo, please take a look at it. As stated in the policy document, the comments and questions on this policy should be mailed to the maemo-developers mailing list with word policy in the subject. If you have a proposal for a policy update or an addition (e.g. concerning public repositories), after the discussion on the mailing list has reached a conclusion, please formulate a summary to a Wiki or www-page and mail link to the page to mailing list. Later on these pages can be linked under Proposals section in the policy Wiki. The policy Wiki pages will be created once the Wiki re-org/transition has been completed. The maemo-policy package referred in the document will also come later. This policy document is modeled after Debian policy manual and makes frequent references to it, so it's recommended to browse through that too: www.debian.org/doc/debian-policy/ - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
