Bug#90511: proposal] disallow multi-distribution uploads

[Santiago Vila <sanvila@unex.es>]

On Tue, 20 Mar 2001, Ben Collins wrote:

> Package: debian-policy
>
> Summary:
>
> Policy should disallow uploads for multiple distributions. Specifically
> this means same version uploads to "stable unstable".

Summary: I object.

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

This is a good reason to forbid uploads to unstable needing an oldlibs
library (make a policy proposal for that and I'll probably second it)
but not to forbid every upload to "stable unstable".

Uploads which do not use unstable oldlibs libraries are legitimate and
should be allowed.

> 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.
>
> So by allowing stable built apps into unstable, we prolong policy
> changes for the distributions aswell.

Uploads to unstable have to follow latest policy (this is already
policy, isn't it?). If you can't satisfy simultaneously policy on
stable and unstable, it follows that you need different uploads.

Uploads which meet the policy requirements for both stable and unstable
are legitimate and should be allowed.

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

Make policy that packages uploaded to unstable compile on unstable then,
if it is not already policy.

Uploads to "stable unstable" which compiles fine in both stable and unstable
are legitimate and should be allowed.

I object to this proposal, because it tries to solve common problems
the wrong way, gratuitously forcing people who do not have those
problems to do things differently.

Thanks.