Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Wed, Mar 21, 2001 at 09:23:08PM -0500, Ben Collins wrote:
> On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
>
> > Any libraries which change the ABI without changing the soname is buggy,
> > period.
>
> Agreed. However, uploading to "stable unstable" is not the correct nor
> intended manner to test them.
Agreed. It is just a side effect. Which I argue is also the case with
your proposal. What you are trying to achieve is merely a side effect,
and one which can be done by other means which are less intrusive.
Please give me your opinions about my proposal to solve your complaint
about obsolete libraries in unstable. In fact, the LFS problem can be
solved through similar mechanism: we can enforce a minimum versioned
dependency in the package (if it depended on libc6 at all that is).
> > > compiling against libc6-dev 2.1.3 does not mean it will compile against
> > > libc6-dev 2.2.2
> >
> > That's a different problem.
>
> Correct, but one which we help to avoid with this proposal, and hope to
> alleviate by raising awareness of the seperation.
My main problem with this whole proposal is that it's trying to decide
for the maintainer as to whether a separate unstable upload is necessary.
My contention is that the maintainer is be the best person to make
that judgement.
If you point is that there are maintainers out there who may not be aware
of the potential problems with "stable unstable", then perhaps we should
start by informing them of the issues involved?
> It does. However, your argument was based on the "helpfulness" of
> building on stable and uploading to unstable. None of which is pertinent
> to this proposal.
Point taken.
> An excellent point. This is about the only valid thing I can forsee
> against this. Quite often builds are done for stable/unstable of kernels
> (I've done some myself for sparc kernels). I'll have to consider this
> one point. However, even with this, you do use a compiler and binutils
> that are quite different between the distributions. Take the upcoming
> gcc3, which will soon replace gcc-2.95 as the system compiler. We will
> have a period where the stable has gcc-2.95 and unstable has gcc-3.0.
> Should not the kernels be buildable by the compiler of the distribution
> for which they are uploaded to?
We take which ever one that produces correct code. If they both do, then
it doesn't matter.
However, I have been doing other "stable unstable" uploads as well, mostly
when there are security holes in my packages. And for the vast majority of
them, I can say that they had none of the pit falls that you have enumerated.
So should this restriction be enforced, I would have to double my efforts
in those cases. Which probably means that unstable will suffer by getting
security fixes later than it would otherwise.
Let me reiterate my main objection to this: the maintainer is the best
person to weigh all the factors involved and to decide whether given that
stable/unstable shares a version to start with, whether to split or
continue to use the same package for both. I don't see why we shouldn't
trust them with this task.
> Actually they are less rare than you think. Most of the builds done by
> the security team incur this, since that usually means the maintainer
> isn't active (and hasn't been since stable released). I don't think the
> rareness of this event outweighs it's purpose since the problems are of
> a severity that justifies it, IMHO of course.
Well if that's the case, then a similar result can be achived by just
forbidding the security team from doing "stable unstable" uploads. I
wouldn't have a problem with that since I don't plan on joining them :)
--
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: