Re: Freeze Please?
"Marcelo E. Magallon" <mmagallo@debian.org> writes:
> I'm saying that your assertion that testing is working ok is self
> delusional.
It depends a bit on what you mean with "working". I use a testing
machine on a daily basis and am perfectly happy with it. In fact if
there were security updates I wouldn't mind using it at home at all
(currently even unstable often gets a mention in DSA's but not
testing).
I understand that I need to be patient now that unstable is undergoing
several huge transforms.
It worked even better close to the woody release when there were
security updates and allowed me to test upgrades, installs and use the
upcoming release fairly safely, while at the same time allowing woody
to be relatively up-to date when released (excluding the effect of the
late security infrastructure switch).
The question is whether it can be as good when a release is not imminent.
> some point we decide that the thing can be released. The reality is
> that a few packages can stop lots of stuff from moving into testing,
This is also blocking regular partial upgrades using apt with is one
of Debian's nicest features. Unfortunately Murphy's law of Debian
upgrade says that at some point during two Debian releases there will
be a libc upgrade :-(
It would be also nice if the dependencies on newly created binaries
weren't so strict: For instance gcc-3.2 in unstable declares a
dependency on libc6 2.3.1-1. However readelf -V on the binaries in
the package show no symbol versions beyond 2.2, combine that with a
check for newly exported symbols and unless I am missing something it
shouldn't be so difficult for the package verify it can run (in theory
at least) against an earlier libc6?
Jan
P.S. Afaics testing would be much better off if glibc 2.3 where pushed
in by hand, despite having several RC bugs (that don't seem so severe
in practice to me)
Reply to: