Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 04:35:58PM -0500, Ben Collins wrote:
> >
> > > > Testing libc6 backward compatibility is not the purpose of
> > > > stable/unstable uploads. That is something that needs to be tested
> > >
> > > But it is a side effect for packages depending on libc6.
> >
> > And side affects are often bad, as they have unforseen problems.
>
> 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
compiling against libc6-dev 2.1.3 does not mean it will compile against
libc6-dev 2.2.2
> > against stable. Yes bug reports can do this. However, when you upload a
> > package built against stable, the buildd's use unstable, so now you have
> > feature skew across architectures. That is a bad thing.
>
> Here's the crux of your current problem. The buildd is broken. In your
> original message, you actually said that the buildd should build on stable
> for such uploads, which would be the correct thing.
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.
> > Also, we want our latest features to be tested. Compiling against stable
> > does not do this, so we have less testing on the things that matter for
> > the next release.
>
> 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.
> > > In any case, I don't see why we should be discussing what technical merits
> > > there are in these uploads, but what technical merits exist in disallowing
> > > them as I haven't seen any of those which are valid either.
> >
> > I've already covered those, but you have blown them all off. I don't see
>
> That's exactly my feeling as well, except the other way around.
>
> > how you can argue against them. Those problems exist for a majority of
> > the uploads that would be done for stable/unstable. Just because the
> > problems don't affect a few possibilities, does not give merit to
> > allowing such things, it just means they don't have problems. Nothing
> > good comes from doing a stable/unstable upload.
>
> The problem is that the bad things which come from it are not due to the
> fact that they are "stable unstable" uploads.
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
toward enforcing same dist compile/upload. Even if we skip this step, it
will eventully come to pass anyway, since you can't enforce that without
disallowing stable/unstable uploads.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: