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 be used by anyone else -- in those > cases SHOULD would be correct. Getting working backtraces will hopefully be less problematic in future releases, so that is OK to me. > 10.4: I would change the backup SHOULD to a MUST. OK. > 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. Do you have a proposal what would be in such a section that is relevant for packaging? Thanks! - Eero _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
