Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 02:00:08AM -0500, Nathanael Nerode wrote:
> Steve Greenland said:
> >On 20-Nov-02, 17:43 (CST), Mike Fedyk <firstname.lastname@example.org> wrote:
> >> On Wed, Nov 20, 2002 at 04:34:20PM -0600, Steve Greenland wrote:
> >> >
> >> > And then when libc6 2.3.x dropped into testing, and broke xvncviewer, it
> >> > would be broken in testing as well as unstable. Yes, I understand that
> >> > it can still happen with packages that haven't yet been built with libc6
> >> > 2.3.x, but I don't see how increasing the problem helps.
> >> No, libc6 didn't break vnc at all AFAICT, but it is the act of having to
> >> upgrade my libc6 just to test vnc, and the fact that now that vnc doesn't
> >> have any RC bugs, it is not in testing ONLY because it depends libc6 2.3.x.
> >> That is the point.
> >And you completely missed mine. VNC WAS AN EXAMPLE, PULLED OUT OF THE AIR
> >BECAUSE *YOU* BROUGHT IT UP.
> >I give up.
> You had a point? I certainly didn't see one.
> Mike is talking about (supposedly) FORWARD-COMPATIBLE upgrades.
> vnc is linked against libc6. If it's linked against the libc6 in testing, it
> works in *both* unstable and testing. Repeat: *both*. When the new libc6
> goes into testing, it will *still* work. Provided the libc6 in unstable
> doesn't break forward compatibility, and if it does, it certainly shouldn't
> go into testing!
Guess what happens when you do this?
You build a bug-free libc6 in unstable, that happens to break VNC
builds. Then you build a bug-free vnc against the testing libc6. They
both make it into testing. And lo and behold testing packages that
can't be built with each other.
I'm not saying this is the only way that can happen; VNC could just
have been built first and never rebuilt against the new libc6. That
happens a lot. But this way you can upload packages which are already
That's bad, mmkay?
> Clearly we need to test the libc6 in unstable to see if it breaks forward
> compatibility. Building packages in unstable against the "old" libc6 (while
> running them aganist the new one!) does just that. If we build everything in
> unstable against the new libc6 we fail to test that. I guess we test the new
> libc6 headers? Really that's *all* we gain by building against the new
> libc6. (I hope the new libc6 headers aren't broken, since that would be
Welcome to changing kernel and libc interfaces. Welcome to the real
world. "Broken" is too simpleminded of a term.
MontaVista Software Debian GNU/Linux Developer