[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
>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 

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: