Bug#90511: proposal] disallow multi-distribution uploads
On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> It's my opinion that same version uploads to stable/unstable are harful
> to archive and distribution integrity.
There is a deep reason why this makes sense, but I think you didn't mention
it explicitely. The reasons you mentioned are practical, but not critical.
The critique is justified, because if it *does* matter if you compile on
stable or unstable it should not say "stable unstable" in the changelog.
(In practice, the set of such package is small for the reasons you
mentioned rightfully).
IMHO, the fundamental and unavoidable reason why we have this problem
is the following:
We don't know in which Packages files (=distributions) a
single binary is (used or) going to be used.
This is a source for conflicts and inconsistencies, because whenever you
want to compile something you have to make sure it will be okay for all
distributions it is going to be used in. As this includes decisions made in
the future[1], there are potential problems you can't address.
The testing area faces this problem as well. It was solved partially by
deciding that a package only enters the testing distributions if it was
available on all to-be-released architectures.
This provides some amount of consistency: You knew that the same version
of a package was used in all released architectures (not too unimportant if
you consider binary-all packages).
This partially addresses the cross-architecture problem. The orthogonal
problem is not solved: cross-releases. We had no solution for this in the
past[1], we don't have a solution for this, and your proposal solves this by
eliminating "merged parts of the branches". After the release, we split off
and keep updates distinct. It is a rough decision, but it is workable.
To solve the generic problem, we would need an entirely different mechanism
to keep track of distributions a package currently belongs to and develop
various strategies what to do with packages belonging to various groups.
(You mentioned some, like compiling for stable and uploading to both).
It is really an interesting problem, but too hard to solve in its generality,
I am afraid [2]. Restricting the possible cases with proposals like yours
is very reasonable. In fact, what you propose has the effect of seperating
the source archives for unstable and stable (without duplicating identical
sources). It's like a split off of the pool at release time (but without
performing the actual split physically). Semantically, it seems to be the
right thing to do.
I think I support your proposal, but I haven't read the exact wording very
thoroughly yet.
Thanks,
Marcus
[1] You can upload to stable and unstable, but you don't know if it will
really be accepted for stable. You can upload to unstable, and you don't
know if or when it will reach testing.
[2] I have not thought this through. I have thought about it a bit, and the
amount of possible cases is stunning. In fact, potentially unlimited.
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: