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 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.
Daniel
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
