Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Wed, Mar 21, 2001 at 04:10:20PM -0500, Ben Collins wrote:
>
> Yes it does help. By allowing stable/unstable uploads, we implicitly
> allow maintainers to do something potentially harmful and with almost
> zero technical gain. By disallowing it, we raise awareness that it is
> most commonly not a good idea.
IMHO you can't solve social problems with technial solutions.
> 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.
> elsewhere. Allowing stable/unstable uploads does not guarantee any of
> this, and is a bad way to test it. For example, many packages should be
> using new interfaces in libc6 for LFS, and not using the db libraries
> that were obsoleted. Compiling against potato increases the lack of LFS
> support in our unstable distribution, and increases the use of obsoleted
> parts of libc6. Neither of these things are technically meritable.
As I have said many times already, this is a *different* problem.
If a package can benefit from LFS and it hasn't been built with LFS, file a
bug report. If a package uses obsolete db packages, file a bug report.
Disallowing "stable unstable" uploads will *not* solve this problem.
> So if you want to test libc6, then get a potato and a sid machine (or
> setup a chroot), and compile your package for potato, and run it in the
> sid system. Don't go uploading a potato compiled package to sid just to
> test libc6's binary compatibility.
But why not? If there's no other reason (all the ones you've listed can
already be solved by bug reports against the relevant packages and won't
be solved by doing this anyway), compiling it on stable is just as good as
compiling it on unstable. In fact, I still contend that it is better
because you are aactually testing whether the libraries involved are
compatible or not.
> > So in fact you're proposing the wrong solution to your problems. Which has
> > the unfortunate side effect that some maintainers will be wasting time
> > doing double compiles that they know will come out to be the same.
>
> No, I'm proposing a large portion of the fix. The other portion may be
> needed, if the problems persist. No amount of policy can stop this
> completely, even if we forbid (and enforce via dinstall) not using
> oldlibs as deps, since that doesn't enforce policy things like doc
> directories and X application defaults, and buildability on unstable.
Well that's where our opinions differ. My perception is that not only
doesn't this solve a large proportion of those problem cases, it also has
the nasty side effect that maintainers of packages where your concerns do
not stand will be wasting time recompiling packages.
> You still have not given any technical merit to allowing stable/unstable
> uploads other than convenience, which is not on my list of technical
> terms.
Obviously you disagree with me about what is a technical merit. IMHO,
testing ABI compatibility of libraries like libc6 is aa technical merit.
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.
--
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: