Steve Greenland said: >On 20-Nov-02, 17:43 (CST), Mike Fedyk <[EMAIL PROTECTED]> 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! 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 pathetic!) It's certainly true that it's simpler to handle things the way they're currently handled; things are not set up to deal with this. In fact, I see *no* way to make the builddaemons handle this automatically, and they probably shouldn't. (How could they tell when a library is supposed to be binary forward-compatible?) But it's obviously worse, because the way things are currently handled, forward compatibility gets less testing, and lots of packages are kept out of testing for no good reason. Note that NONE of this argument applies to upgrades which do *not* guarantee binary forward-compatibility. So it's kind of a corner case, albeit an interesting one. If forward-compatible libraries on which everyone depends, such as libc6, were cooked in 'experimental' for long enough so that they could be guaranteed to go from unstable into testing pretty darn quick, then this wouldn't be an issue which caused meaningful problems. I don't know that that's really possible either.
