Numbered sections in wiki (was: Re: Packaging guidelines)
Hi, Graham Cobb wrote: 0) I have a meta-comment: to facilitate discussion, the sections of the document should be numbered. This is a user-preference in Mediawiki: in My preferences, in the Misc tab, check Auto-number headings to have sections in all pages numbered. Sections are numbered in the table of contents in any case, so there is no problem with referring to section 4.1 (Package relationships) - I'd like to see people include the names in any case, because section numbers can change in a wiki after edits. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging guidelines
Hi, 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
Packaging guidelines
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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging guidelines
Dnia środa, 28 kwietnia 2010 o 21:10:47 Graham Cobb napisał(a): Daniel Wilms has proposed some new Maemo packaging rules at http://wiki.maemo.org/Packaging/Guidelines. I have a number of comments: I have one: where is lintian? If you (Daniel) want to set guidelines then give us a tool which will check for them. Debian packaging is easy because it runs lintian on resulting packages and refuse to import packages which do not pass. So far maemo autobuilder quality control is based on 'let few people look at my package' which can be bypassed without problems. Without automatic checks new rules are useless. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging guidelines
Are you kidding ? It s already a pain ... And that section list isn t usefull for maemo, no theme for example. Maemo doesn’t currently use package priorities for anything. For future compatibility, please conform to the Debian policy. Maybe but there is a repository priority. Separating files into binary packages (new section) Hum so it s mean 45 gcompris packages in HAM ... (just one example) Localiation packages Could be a solution to let think user that there is plentapps available. Someone have already use HAM ? Scroll to the end of the list is a pain. Just my two cents. 2010/4/28 Marcin Jusnzkiewicz mar...@juszkiewicz.com.pl: Dnia środa, 28 kwietnia 2010 o 21:10:47 Graham Cobb napisał(a): Daniel Wilms has proposed some new Maemo packaging rules at http://wiki.maemo.org/Packaging/Guidelines. I have a number of comments: I have one: where is lintian? If you (Daniel) want to set guidelines then give us a tool which will check for them. Debian packaging is easy because it runs lintian on resulting packages and refuse to import packages which do not pass. So far maemo autobuilder quality control is based on 'let few people look at my package' which can be bypassed without problems. Without automatic checks new rules are useless. Regards, -- JID: ...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Benoît HERVIER, Khertan Software - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
