----- Original Message ----- From: "Ben Collins" <[EMAIL PROTECTED]> To: "Herbert Xu" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 22, 2001 3:23 AM Subject: 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 \ > ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' > `---=========------=======-------------=-=-----=-===-======-------=--=---' > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
