[maemo-developers] policy: maemo packaging policy -draft

[From: Guillem Jover]

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.

regards,
guillem