release policy changes
Hi,
I looked through our release policy. There are some changes I think we
should or need to make.
One addition I would like very much to see is:
A library that is included in a package in Debian must be linked to
dynamically; for static-only executables like sash also static linking
to that other library package is accepted. Importing and using the
source code of any library into another package is not permited.
Rationale:
Some libraries are provided multiple in Debian, IIRC e.g. libz. That is
bad from general QA (as usually this is just an old version, and normale
bug fixes don't go in), and especially bad if there is a security update
necessary.
Another addition that I would like to see is:
Packages must not change neither their build-dependencies nor their
changelog entries during rebuild.
Rationale:
Well, the contents of both are decisions of the maintainer. It is IMHO
very bad if a package starts to change build dependencies during a NMU
or an security upload, and even worse if the maintainer is "adjusted" in
the binary packages built on a buildd.
Issues that may need to be clarified are IMHO:
Documentation in main and contrib must be freely distributable,
and wherever possible should be under a DFSG-free license. This
will likely become a requirement post-sarge.
well, that probably neds to be changed to: "Documentation in main and
contrib must meet the DFSG", and, so, can be merged with the first
sentence to "Code and Documentation ...".
The reference to non-US can be dropped in 2.
About:
Shared libraries must be compiled with -fPIC, and normally static
libraries must not be. If you need to provide static libraries
compiled with -fPIC, call it "<libname>_pic.a".
There was some discussion last year about a library that was compiled
w/o PIC on i386 to better utilze the few registers (and that was
reasonable faster). We might want to switch that for that reason to a
"-fPIC on !i386, ...". Of course, that probably needs some technical
discussions.
Do we need to clarify the MTA-section? I think the current policy of
"MTA must fullfil all of LSB for the sendmail-binary, except if it
conflicts with the lsb-package" is sensible. But perhaps that
information needs to be added. (The major issue is that -bs is by far
not implemented by some MTAs like nullmailer, because they're
local-only, and -bs is for BSMTP which is a remote protocol.)
LSB version: I think we might want to upgrade the version number.
Python: I'm not happy with the current python policy at all, because
that gives us too much forward-conflicts. However, I think best is to
speak with Matthias Klose on debconf, and see if there is some progress
possible.
General: Some resorting and better formating may be a good idea.
I'd appreciate comments. Of course, this list is just meant as starter
for us, and I know that some of the ideas require discussion e.g. on
-devel if we want to go that way.
Cheers,
Andi
Reply to: