Re: Why are new package versions depending on libc6 in unstable?
Steve Greenland said:
>On 20-Nov-02, 17:43 (CST), Mike Fedyk <mfedyk@matchmail.com> 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.
Reply to: