Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
On Thu, Mar 22, 2001 at 07:45:27AM +1100, Herbert Xu wrote:
> Ben Collins <bcollins@debian.org> wrote:
>
> > As for the first. Multi distributions occur so infrequently that it
> > should not be a problem to do this. Most of the time a package is
> > already diverged between stable and unstable, so two uploads are still
> > required in that case for security fixes. Enforcing this just means we
> > have more consistency. Allowing it for convenience makes no technical
> > sense.
>
> Perhaps this has been your experience (understably since you maintain a lot
> of library packages that are actively developed). However, im my
> experience, I've certainly done my fair share of "stable unstabe" uploads,
> and I do not welcome the prospect of having to double those just to solve
> some non-existant problem.
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.
> > As for allowing them in cases where they don't fall into any of my
> > listed points of breakage, I ask that you give a solid technical reason
> > why even those should be allowed, other than simple convienience. I see
> > no reason for it. In fact, the only technical reason was back when we
> > had frozen/unstable uploads, and they do not occur any longer.
>
> As I said, it is a good thing to have packages compiled against old libc-dev
> packages since that actually tests whether libc6 has been true its words
> when it says that its ABI is still the same. In any case, IMHO the more
> interesting question is why they shouldn't be allowed in this case?
Testing libc6 backward compatibility is not the purpose of
stable/unstable uploads. That is something that needs to be tested
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.
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.
> However, my main objection to this proposal is that it solves none of your
> problems as disallowing simultaneous uploads does not equate to disallowing
> the building of unstable packages on stable.
>
> 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.
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.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: