[maemo-developers] Packaging guidelines

[From: Graham Cobb]

Daniel Wilms has proposed some new Maemo packaging rules at 
http://wiki.maemo.org/Packaging/Guidelines.  I have a number of comments:

0) I have a meta-comment: to facilitate discussion, the sections of the 
document should be numbered.  

1) These feel like rules, not guidelines, and some of them are much too 
strict.  If we adopt unnecessary rules then what will happen is that people 
will set up alternative repositories which do not have any rules (or any QA 
process), and many developers will just migrate to the alternative 
repository.  

Much better to have the minimum necessary rules, simple and quick process, and 
human judgement to assess the risk of violation of the guidelines.  By all 
means create guidelines which are recommendations, but keep the number of 
actual rules to the absolute minimum necessary.

2) It is not clearly specified what is the scope of these guidelines.  I 
assume that the plan is that packages for Maemo Extras (free or not free) 
will not be accepted if they do not conform to these rules, with no 
exceptions.  If that is the case, then the rules need to say so.

Note that there are several other possible interpretations:

- The rules could apply to all packages which are to be listed in Maemo 
Downloads, even if they are from external repositories.

- The rules could apply to all packages submitted to the autobuilder.

- The rules could be intended to apply to all packages which can ever be 
installed on a Maemo system (this is currently unenforceable but that could 
be the intent).

- The rules could only apply to user-visible packages, not all packages in the 
repository.

- The rules could really be guidelines: in other words they should normally be 
followed but exceptions will be allowed if some people (who?) can be 
convinced there is a valid reason.  If this is not the case, the document 
should be renamed to "Requirements" instead of "Guidelines".

3) Differences between corresponding Maemo and Debian packages .  This 
requirement should be deleted.  There are many very reasonable reasons for 
incompatible differences between package X in Maemo and in Debian.  Some 
examples:

- Libraries compiled with different options because different features or 
dependencies are available in Maemo

- Libraries with capabilities disabled because the porter is not using those 
features and hence cannot test them

- Applications with features disabled because the porter has not got around to 
porting them

- Applications with features disabled because they aren't relevant use cases 
on a Maemo device or cannot work effectively on a Maemo device

Note that not even Nokia-supplied system libraries comply with this 
requirement!

4) Maemo packages that are not yet in Debian.  This is not a requirement Maemo 
should or can impose and should be deleted.  There are no requirements on 
what is made available in any VCS, only that the source package is uploaded 
for free packages.

Note that in GPE, I do choose to include the Maemo packaging in the /debian 
directories in SVN, but that the Debian packager explicitly insists that they 
be removed before tar files are exported, as he has his own packaging 
directories and does not want /debian directories from upstream interfering 
with the "real" debian packaging!

5) Separating files into binary packages.  This should say:

If this requires packaging the sources differently from the upstream 
distribution (Debian), the packaging changes MAY be propagated back to 
upstream.

Maemo packaging should not require any changes to upstream packaging -- it is 
entirely up to the Maemo package maintainer, and nothing to do with the Maemo 
community, if the maintainer wishes to try to propagate packing changes 
upstream.  It may be better just to delete the sentence altogether.

6) Debug packages.  I am not convinced this should be a SHOULD.  Why would 
most application developers want to go to the effort to create debug 
packages?  No one is going to try to debug or profile their apps for them -- 
it is just a waste of time.  On the other hand, for libraries, it is useful 
to have them in all -dev packages in roder to make debugging use of the 
libraries easier.  I would prefer to replace this with something like:

Debug symbol files MUST NOT be included in binary packages (applications or 
libraries) intended to be installed on user machines.  Library symbol files 
SHOULD be included in -dev packages or in -dbg packages for the library.  
Application symbol files MAY be included in -dbg packages for the 
application.

7) Original sources.  There is no reason to make that a MUST.

Graham