[maemo-developers] Packaging guidelines

From: daniel wilms daniel.wilms at nokia.com
Date: Thu Apr 29 13:18:57 EEST 2010

ext Graham Cobb wrote:
> 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.

I agree, and this was the reason for not calling it policy. The 
guidelines mention special requirements, which you should consider, 
packaging for Maemo. I think these guidelines help to give a bit more 
detailed overview, of what you should look at if packaging an 
application or testing it for extras. The human judgement is still 
necessary, if you consider something as a blocker or not to vote up or 
down. Further this is a start. As I wrote in my blog, the discussion is 
open and appreciated, and in my opinion it is easier to start a 
discussion, having some basis to discuss about.

> 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".

Some kind of packaging policy was requested by the community since a 
long time already. I share your opinion that we have to be careful, that 
it won't get too restricted. But these questions are exactly, what I'm 
glad to see being discussed here. The packaging policy before was 
maintained by Nokia, but in my opinion it is most valuable for the 
community. So let's find some solution in a discussion on this list. I 
would go for your last point and the intend were guidelines and not to 
create requirements . But I think partially there is a little 
misunderstanding: I didn't set the guidelines, as it was mentioned in 
some other mails, I just had the task to push that forward that the 
discussion can be started.

> 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!

But in those cases it says, that you can set the bug as a WONTFIX for 
obvious reasons. So I see it more as a description of the common practice.

> 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.

I agree on these points. Most of them are based on the fact that we took 
the previous packaging policy as the basis for these guidelines. I think 
in some cases it makes sense to weaken the guidelines as requested.

More information about the maemo-developers mailing list