Re: Why are new package versions depending on libc6 in unstable?
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.
Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 02:00:08AM -0500, Nathanael Nerode wrote: 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 Why would you have to build those packages? Just install the new libc on any random unstable system, and poof, hundreds or thousands of packages built against the old one are instantly ready to test. And when it gets to testing, probably even more.
Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 08:36:43AM -0600, John Goerzen wrote: On Sat, Nov 23, 2002 at 02:00:08AM -0500, Nathanael Nerode wrote: 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 Why would you have to build those packages? Just install the new libc on any random unstable system, and poof, hundreds or thousands of packages built against the old one are instantly ready to test. You've never ever encountered something that failed to build with a newer libc6-dev? sys/time.h versus time.h is an obvious example from a while back. We need to know about this kind of thing. -- Colin Watson [EMAIL PROTECTED]
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 [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! 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 unbuildable. 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 pathetic!) Welcome to changing kernel and libc interfaces. Welcome to the real world. Broken is too simpleminded of a term. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Why are new package versions depending on libc6 in unstable?
Daniel Jacobowitz [EMAIL PROTECTED] wrote:
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
unbuildable.
That's bad, mmkay?
As you noted, this would happen anyway if VNC was uploaded first. If
we were building against testing, it would mean that this problem might
only be noticed after libc6 enters testing.
However, up until now, most of these changes have been bugs in the
application rather than glibc. This means that it is the application
which has to be fixed, and most of them will not show obvious signs of
breakage until a new version is uploaded to unstable. In fact, it is
quite likely that for rarely uploaded packages, this situation might
still exist after a Debian release is made. IMHO in this case it doesn't
really matter if we only see the breakage of the application after
libc6 enters testing.
Of course, if glibc became more buggy such that build breakages where
the fault lies with it is the norm of the day, then the conclusion would
not stand. But I have not lost all faith in the glibc maintainers yet.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 12:13:42PM -0500, Daniel Jacobowitz wrote: 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 unbuildable. That's bad, mmkay? It's no different than the current situation. You admitted yourself that it could happen right now if nobody uploaded a new vnc when the new libc is in unstable. So I'm not sure what the point is. The only way to deal with that is to continuously rebuild testing. (Isn't somebody doing this already?) Mike Stone
Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 05:25:28PM -0500, Michael Stone wrote: On Sat, Nov 23, 2002 at 12:13:42PM -0500, Daniel Jacobowitz wrote: 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 unbuildable. That's bad, mmkay? It's no different than the current situation. You admitted yourself that it could happen right now if nobody uploaded a new vnc when the new libc is in unstable. So I'm not sure what the point is. The only way to deal with that is to continuously rebuild testing. (Isn't somebody doing this already?) Why not build against testing by default, and have something auto-build against unstable and report to the maintainers of the package that won't build and the libary it won't build against whenever there is an error?
Re: Why are new package versions depending on libc6 in unstable?
On Sat, Nov 23, 2002 at 04:32:22PM -0800, Mike Fedyk wrote: Why not build against testing by default, and have something auto-build against unstable and report to the maintainers of the package that won't build and the libary it won't build against whenever there is an error? Many problems, such as the libpng2/libpng3 linkage chaos at the beginning of this year, only occur when you actually try to run things. Building against unstable allowed us to identify the problem in the libpng development libraries as soon as possible and deal with it. -- Colin Watson [EMAIL PROTECTED]
Re: Why are new package versions depending on libc6 in unstable?
On Fri, Nov 22, 2002 at 02:29:48AM +0100, Tollef Fog Heen wrote: Nothing is installed from experimental because of dependencies.. you have to be explicit about each and every package. Either it automatically installs upgraded packages, potentially clobbering something you don't want clobbered, or it would be a flaming pain to select every one of a couple hundred upgraded packages (e.g., in kde) one at a time. Neither option makes me think yay, let's use experimental. Mike Stone
Re: Why are new package versions depending on libc6 in unstable?
On Thu, Nov 21, 2002 at 05:40:39PM -0800, Mike Fedyk wrote: Nice, (btw, this is documented in man apt_preferences) but how do you know there is a new version available in experemental from apt-cache? apt-cache policy -- - mdz
Re: Why are new package versions depending on libc6 in unstable?
* Michael Stone | On Thu, Nov 21, 2002 at 10:26:37AM -0800, Mike Fedyk wrote: | Yes, please use experemental more than it is now. | | Please never use experimental. I much prefer private apt repositories | with discrete units (e.g., an X repository or gnome repository) over | experimental, which is a random collection of software, some of which | might really toast your system. Nothing is installed from experimental because of dependencies.. you have to be explicit about each and every package. (Unless you have overridden that using apt's preference, in which case you should know that you are out on a limb). AIUI, anyhow. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Why are new package versions depending on libc6 in unstable?
On Fri, Nov 22, 2002 at 02:29:48AM +0100, Tollef Fog Heen wrote: * Michael Stone | On Thu, Nov 21, 2002 at 10:26:37AM -0800, Mike Fedyk wrote: | Yes, please use experemental more than it is now. | | Please never use experimental. I much prefer private apt repositories | with discrete units (e.g., an X repository or gnome repository) over | experimental, which is a random collection of software, some of which | might really toast your system. Nothing is installed from experimental because of dependencies.. you have to be explicit about each and every package. (Unless you have overridden that using apt's preference, in which case you should know that you are out on a limb). AIUI, anyhow. Nice, (btw, this is documented in man apt_preferences) but how do you know there is a new version available in experemental from apt-cache? Anyway, with this, experemental looks even better. :)
Re: Why are new package versions depending on libc6 in unstable?
On Thu, Nov 21, 2002 at 05:40:39PM -0800, Mike Fedyk [EMAIL PROTECTED] was heard to say: Nice, (btw, this is documented in man apt_preferences) but how do you know there is a new version available in experemental from apt-cache? apt-cache show or showpkg will show this.. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | The spork is strong with him... -- Fluble | \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
