Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 04:51:06PM -0500, Ben Collins wrote:
> > On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
> >
> > > Are you saying that packages compiled against old libc6-dev packages are
> > > not guarranteed to work with a new libc6? Well, better tell that to all
> > > the application vendors out there.
> >
> > No, but other libraries may show this problem. Not just that, but
>
> 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.
> > 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.
> > No, you misinterpret this. I am saying that if you build against
> > "stable" (see above, that is what I said), then the buildd's will
> > compile against unstable for an unstable upload. So you argument about
> > allowing testing of backward compatibility applies here. You are
> > creating feature skew.
>
> Well for "stable unstable" uploads, the buildd should build it on stable,
> and upload it to "stable unstable". IIRC this is what you said in your
> first message.
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.
> > > Disallowing "stable unstable" uploads has a very small effect on this.
> >
> > That's arguable, and not technically founded. However, allowing
> > stable/unstable uploads implicitly allows this to happen. So if we
> > enforce this in the long run, as you suggest, we will have to stop
> > stable/unstable uploads anyway.
>
> Not for me. Most of my "stable unstable" uploads are for the kernels
> which do not interact with libraries in any way.
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?
> > Of course they are. It means the packages have to be compiled on stable
> > and uploaded to unstable. It means there is no way around that, and
> > problems do occur because of it. By disallowing them, we are a step
>
> Well my point is that disallowing "stable unstable" doesn't solve those
> problems for most packages, as "stable unstable" uploads are rare to start
> with. And for packages which don't have these problems, this incurs
> significant overhead on the part of the maintainer.
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.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: