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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
