Bug#90511: proposal] disallow multi-distribution uploads
Ben Collins <bcollins@debian.org> wrote:
> Running a buildd, I have the problem of builds that come in for stable
> and unstable. Currently this means the buildd performs the compile on
> stable, and either uploads to "stable unstable", or as it were
Is there a reason why this option won't work?
> It's my opinion that same version uploads to stable/unstable are harful
> to archive and distribution integrity. I've talked this over with James
> Troup, and he seems to agree with the points below, and is considering
> enforcing them via dinstall checks. My intention is to get the weight
> of policy behind this.
I disagree. Allowing uploads to both stable and unstable reduces maintainer
load, so that they can spend their precious time doing useful work rather
than needlessly recompiling things.
> Technical reasoning:
> 1) Building for "stable unstable" means that 99% of the time the build
> is performed on a box running "stable". So the package will be compiled
> against "stable" libraries. Now we all know that most of the major
> libraries will go on to new major versions between releases. Ncurses (4
> to 5 between slink and potato), readline (2 to 4 between slink and
> potato), gnome (several revisions during potato development, and others
> now), libstdc++ (which changes with the libc6 major upgrades), etc...
> Now, a lot of libraries keep an oldlib around for backward compatibility
> of packages that have not been recompiled for the newest version of the
> lib. This is a less than optimal situation since it must be maintained
> just like any other package. If libncurses4 is in stable, and
> libncurses5 is in unstable (with the 4 version around only for backward
> compat), then builds in unstable should be using the libncurses5.
> However, someone compiling for "stable unstable" uneedingly prolongs
> this oldlib's life.
But you need to keep old libraries around anyway for compatibility with
other Linux distributions. We're not the only Linux distribution here.
In fact, having some unstable packages compiled on stable is a
Good Thing (TM). It means that we actually test whether our libraries
are lying when they claim to have kept their ABI intact (glibc would be
a prime example). You won't be able to do this if everybody compiled their
unstable packages against unstable.
Of course, if a package doesn't compile on unstable, that would be a
different matter, and a severity serious bug.
> 2) Policy changes. This is probably the worst case. We all know that
> policy abiding build-helpers change between releases just like policy
> does. Take the usr/doc->usr/share/doc changeover scripts, and the X
> default scripts used and hardcoded during the build. Building on stable
> and unstable produces 2 different packages, abiding by two different
> policies.
This is a separate issue. If there's no way to build a package such that
it complies with both sets of policies, then it shouldn't be built for both
distributions. Indeed, you can already file serious bugs against such
packages armed with our current policy.
> 3) Build failures. It is commonly the case that a package built on
> stable will not compile on unstable, even though it works runtime wise.
That is a problem, but I don't think it is serious enough to warrant the
prohibition of multi-distribution uploads.
> Issues:
> The only issue I forsee is the likely even of where an upload to stable
> and unstable is desired. I suggest that policy specify this to be done:
> If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
> not changed since stable was released) and an upload must be done for
> both stable and unstable of 1.0-2, then the stable upload must be
> 1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
> reason for the .90 is similar in spirit to how glibc starts a
> pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).
If the package in question cannot be uploaded to both stable and unstable
for reasons such as policy disparity, library compatibility, then yes this
is what should be done. But that's what we've been doing anyway. Except
of course that the version number is 1.0-1potato.1 (replace potato with the
name of the current stable distribution). Otherwise, IMHO this just wastes
the time of the maintainers involved.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: