Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 22, 2003 at 11:45:08PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Because the interface changed or because the previous version was buggy? I have always assumed the first reason, but it seems many maintainers are using the second. first reason, interface changes. libcurl provides a function (curl_easy_setopt) which is used to set options for the run. if new options are added i have to change shlibs, i cannot know whether a program linking the new libcurl uses any new option. hence, i cannot allow its installation with an older libcurl. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Colin Watson wrote: The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Because the interface changed or because the previous version was buggy? I have always assumed the first reason, but it seems many maintainers are using the second. While moderately helpful to users of unstable, using shlibs to push bug fixes can be very destructive to the testing release. It stops other packages from getting in, while not always fixing the bug anyway (if the fixed version gets stuck in unstable, which is not uncommon). I found only little in the debian developer manuals detailing how version dependencies should, and should not, be used. Did I miss a section about this, or is there a general consensus about the issue? -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, 22 Apr 2003, Björn Stenberg wrote: Colin Watson wrote: The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Because the interface changed or because the previous version was buggy? Because of interface changes, ONLY. Screwing with shlibs due because a previous version was buggy is a very bad idea. I have always assumed the first reason, but it seems many maintainers are using the second. Well, bring the issue up with them. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 22, 2003 at 11:45:08PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Because the interface changed or because the previous version was buggy? I have always assumed the first reason, but it seems many maintainers are using the second. Can we have some examples? I've seen maintainers occasionally doing that with ordinary dependencies, but not with libraries' shlibs files. While moderately helpful to users of unstable, using shlibs to push bug fixes can be very destructive to the testing release. It stops other packages from getting in, while not always fixing the bug anyway (if the fixed version gets stuck in unstable, which is not uncommon). Remember that one of the major points of testing is to keep bugs out. If there's some bugginess in some group of packages in unstable then it's better that it be kept out than rushed into testing as quickly as possible. Getting it into testing is only good if the it in question is worthy. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Colin Watson wrote: forcing other packages to always depend on the latest version of them No, that's not what shlibdeps do. Right, it does not force the latest, only the version that is installed on the machine it runs on. But isn't the effect essentially the same, since most people/robots that build for unstable will likely have farily recent library versions? If whatever library versions are present at the time of building are defined as the minimum requirements, doesn't that mean that packages which are in stable today would not even be accepted into testing if they were rebuilt? -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: forcing other packages to always depend on the latest version of them No, that's not what shlibdeps do. Right, it does not force the latest, only the version that is installed on the machine it runs on. No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps -- Colin Watson [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Colin Watson wrote: No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Lovely, so it's simply the other way around (as Adam Conrad said already). Thanks. However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? If it was a frequently asked (and answered) question, I would expect a ton of list archive links to have been dumped on me by now. I have no qualms about squeezing blood from stone, but it doesn't exactly speed the discussion nor minimize my annoying questions. -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, 16 Apr 2003, Björn Stenberg wrote: However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. The issue is: Define BOGUS. Most of the time, the maintainers of the -dev packages know very well why they have changed the versioned dependencies. It is also a no-granularity solution, for which the only alternative is full-blown symbol versioning as done by glibc (i.e. you keep old ABIs around, even!). Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? If it was a frequently asked (and answered) The shlib dep system is well explained in the developer documentation, and it is almost never a matter of curiosity of non-developers... it is also the best that can be done AFAIK. Only people building packages need to direct interact with it, and only if they are responsible for a library package, even... otherwise it is all automatic. As for shlib information keeping stuff out of testing, that's the wrong POV. THAT *is* the entire charter of testing: if we don't know it will work, don't let it in. The system is working as designed. If you want the packages to flow in testing, you need to make sure their dependencies do. I pay little attention to testing, so I don't know exactly what is freezing it right now, but the truth is: people who care about testing are encouraged to clean up the bugs *in unstable* that are holding things from testing, or to go away (fixing the bugs are the ONLY desired way to get things into testing). Sometimes the bugs are not in packages, but in infrastructure or something else... but that's rare. There isn't much else we can do, really. We have to keep the distribution in testing and stable coherent, so that means fix stuff in unstable, and only let it get to testing when dependencies are satisfied (and new bugs not added, subject to some manual control by aj). If you need to live in the bleeding edge (I do), then use unstable and take the proper precautions to not get caught in major breakages just when you needed your system working the most... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpmDdFc1myA5.pgp Description: PGP signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 02:56:21PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Lovely, so it's simply the other way around (as Adam Conrad said already). Thanks. However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. The dependencies aren't bogus (apart from the occasional mistake in a library's shlibs files). The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Stable is irrelevant here, because the package built for stable was built against an older version of the library. Binary dependencies are not the same as source dependencies. Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? The only practical and correct way that I know of to improve the situation would be to figure out some way to calculate package dependencies from symbol versions in certain libraries. That's very difficult and would probably involve a lot more work on the part of the maintainers of those libraries even if it could be implemented, though. I think it is much more productive to try to get infrastructure packages into a good enough state that major upgrades can move into testing more quickly: that is, fix real bugs! Mailing package maintainers asking them to loosen their shared library dependencies is not useful and is sometimes actively counterproductive (I've seen maintainers messing around trying to upload packages built against testing, not realizing that the autobuilders all build against unstable so this won't do any good anyway, which increases the time their package has to wait over what would have happened if they'd just left well alone). Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Björn Stenberg wrote: Right, it does not force the latest, only the version that is installed on the machine it runs on. Not quite. The shlibs file just declares that a package which includes a program linking against, say, libfoo.so.0 should depend on a package called, say, libfoo0. The possibility to version that dependency exists and is actively used. A common example is when a library fixes a bug affecting its clients. A versioned dependency is added to make sure that the newly compiled packages can't be installed with the buggy versions of the library. That's just one example. There are only a few pathological cases where the shlibs file forces newly compiled packags to use the lastest release of the library package. If whatever library versions are present at the time of building are defined as the minimum requirements, doesn't that mean that packages which are in stable today would not even be accepted into testing if they were rebuilt? That could happen, yes. Some hours ago I uploaded a package which is for all _practical_ purposes an identical copy of the package in stable. It will probably remain stuck in unstable for a long while. Marcelo
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Hi, Through the shlibdeps system. Probably, the libgcc and libc packages decided that on ARM they should have those versioned dependencies. The libcurl2 package needs not do anything by itself to pick them up. Note that the version shown is simply the current libgcc.so version. dpkg-shlibdeps has no idea whether an older version would be sufficient, so it plays safe. checking whether to use libgcc... no That is because the decision to do this is made by the system's default ld script, so _explicit_ linking to libgcc, which is what this test tries to figure out, is unnecessary. -- Matthias -- It is fruitless: to become lachrymose over precipitately departed lactate fluid.
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Matthias Urlichs wrote: Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Note that the version shown is simply the current libgcc.so version. Current as of when? When the upload was done? dpkg-shlibdeps has no idea whether an older version would be sufficient, so it plays safe. Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Note: I don't have a suggestion for a better method right now, I'm just trying to understand the implications of the current system. -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 15, 2003 at 10:43:50PM +0200, Bj?rn Stenberg wrote: Matthias Urlichs wrote: Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Note that the version shown is simply the current libgcc.so version. Current as of when? When the upload was done? Current at package build time, that is when dpkg-shlibdeps is run. dpkg-shlibdeps has no idea whether an older version would be sufficient, so it plays safe. Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Not often. Most slow release libraries are strongly backwards compatible. When it does become a problem, it can be terrible for a few weeks. Lots of packages need to be rebuilt. Unstable becomes, well, unstable. Then things get back to the normal level of chaos. Jim Penny Note: I don't have a suggestion for a better method right now, I'm just trying to understand the implications of the current system. -- Bj?rn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Björn Stenberg wrote: Matthias Urlichs wrote: Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Note that the version shown is simply the current libgcc.so version. Current as of when? When the upload was done? Current as of when libgcc1 froze the shlibs, which was recently. lucifer:~# dpkg -l libgcc1 |grep ^ii ii libgcc13.2.3-0pre8GCC support library lucifer:~# cat /var/lib/dpkg/info/libgcc1.shlibs libgcc_s 1 libgcc1 (= 1:3.2.3-0pre6) lucifer:~# zgrep Freeze /usr/share/doc/libgcc1/changelog.Debian.gz * Freeze the shlibs dependencies to (= 1:3.2.3-0pre6). ... Adam
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Jim Penny wrote: Björn Stenberg wrote: Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Not often. Most slow release libraries are strongly backwards compatible. That was my point. Since these libs are strongly backwards compatible, forcing other packages to always depend on the latest version of them means packages are held back for invalid reasons. -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 15, 2003 at 11:48:04PM +0200, Bj?rn Stenberg wrote: Jim Penny wrote: Bj?rn Stenberg wrote: Isn't this a problem? Especially for packages depending on libraries with long release cycles, such as libgcc1 and libc6. Not often. Most slow release libraries are strongly backwards compatible. That was my point. Since these libs are strongly backwards compatible, forcing other packages to always depend on the latest version of them No, that's not what shlibdeps do. -- Colin Watson [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote: i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. You'll find it does on arm and probably one or two other architectures, but in particular: Package: libcurl2 Architecture: arm Version: 7.10.4-1 Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpQwujKrlsd7.pgp Description: PGP signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Hi, On Mon, 14 Apr 2003 13:56:48 +, Domenico Andreoli wrote: i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. If it is built with gcc-3.2 and it needs a symbol from libgcc-3.2, then the resulting package will depend on gcc-3.2. I can't think of an easy fix. The packages in unstable are supposed to move to testing as-is, and IMHO automatically trying to re-build them in testing when that doesn't work because of auto-generated dependencies (how do you find those?) sort of defeats the whole idea. Maybe it's time to force gcc-3.2 into testing..? -- Matthias
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
$ ldd `which curl` libcurl.so.2 = /usr/lib/libcurl.so.2 (0x27ae1000) libssl.so.0.9.7 = /usr/lib/i686/cmov/libssl.so.0.9.7 (0x27b06000) libcrypto.so.0.9.7 = /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x27b35000) libdl.so.2 = /lib/libdl.so.2 (0x27c25000) libz.so.1 = /lib/libz.so.1 (0x27c28000) libc.so.6 = /lib/libc.so.6 (0x27c35000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x27ac3000) $ hmmm... doesn't look as if it depend on any ligcc-3.2 On Mon, Apr 14, 2003 at 04:52:00PM +0200, Matthias Urlichs wrote: Hi, On Mon, 14 Apr 2003 13:56:48 +, Domenico Andreoli wrote: i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. If it is built with gcc-3.2 and it needs a symbol from libgcc-3.2, then the resulting package will depend on gcc-3.2. I can't think of an easy fix. The packages in unstable are supposed to move to testing as-is, and IMHO automatically trying to re-build them in testing when that doesn't work because of auto-generated dependencies (how do you find those?) sort of defeats the whole idea. Maybe it's time to force gcc-3.2 into testing..? -- Matthias -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote: i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. anyway debian has migrated to gcc 3.2 as default compiler and i build curl with gcc 3.2 since a couple of releases ago. maybe it is required someway. i'm CC debian-devel@, maybe some kind soul might help here On some platforms (i386 is not one of them), binaries are dynamically linked against libgcc, which comes from the gcc-3.2 source package. As a result, your package can't enter testing until gcc-3.2 itself does. -- Steve Langasek postmodern programmer pgpiZJ8DVB9dK.pgp Description: PGP signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Hi, Domenico Andreoli wrote: $ ldd `which curl` [ no libgcc or similar ] Duh. You're right. I admit to not being able to think of any other good (i.e. not-a-bug) reason why this dependency should be there, then. Since one of my packages has the same problem, I'll go and check why dpkg-shlibdeps (what else??) thinks so. -- Matthias Urlichs|noris network AG|http://smurf.noris.de/ -- My dungeon cell decor will not feature exposed pipes. While they add to the gloomy atmosphere, they are good conductors of vibrations and a lot of prisoners know Morse code. -- The Evil Overlord List pgprRkWZGPv67.pgp Description: signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Mon, Apr 14, 2003 at 05:17:33PM +0200, Matthias Urlichs wrote: Duh. You're right. I admit to not being able to think of any other good (i.e. not-a-bug) reason why this dependency should be there, then. Since one of my packages has the same problem, I'll go and check why dpkg-shlibdeps (what else??) thinks so. package dependencies are ok, so dpkg-shlibdeps is not wrong. at least on i386. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Mon, Apr 14, 2003 at 03:56:48PM +0200, Domenico Andreoli wrote: i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. libcurl2 and libcurl2-dbg depend on libgcc1 on arm. libgcc1 supplies certain parts of the C runtime. There isn't really anything package maintainers can do about this. Björn, I would suggest you concentrate on other problems for now, such as packages that have been held out for a long time. There are plenty of them. -- Colin Watson [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Hi, I'll go and check why dpkg-shlibdeps (what else??) thinks so. Well, it doesn't. Not on i386 and ppc, anyway. As aj wrote, though, apparently it does on arm. :-/ -- Matthias Urlichs|noris network AG|http://smurf.noris.de/ -- We learn from history that we learn nothing from history. -- George Bernard Shaw pgpLtjqqxrScp.pgp Description: signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Matthias Urlichs writes: Maybe it's time to force gcc-3.2 into testing..? No, it should go in after binutils gets into testing.
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Anthony Towns wrote: You'll find it does on arm and probably one or two other architectures, but in particular: Package: libcurl2 Architecture: arm Version: 7.10.4-1 Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Sorry for being a pain, but how are these dependencies assigned? libgcc1 is already in both testing and stable. How is it decided that libcurl2 requires this specific version? It appears neither the package maintainer nor the upstream author made this decision (or even knew about it). Also, the arm build log for arm contains the following line: checking whether to use libgcc... no -- Björn
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, 15 Apr 2003, Björn Stenberg wrote: Package: libcurl2 Architecture: arm Version: 7.10.4-1 Depends: libc6 (= 2.3.1-1), libgcc1 (= 1:3.2.3-0pre6), ... Sorry for being a pain, but how are these dependencies assigned? Through the shlibdeps system. Probably, the libgcc and libc packages decided that on ARM they should have those versioned dependencies. The libcurl2 package needs not do anything by itself to pick them up. Also, the arm build log for arm contains the following line: checking whether to use libgcc... no Then find out why something in the package linked to libgcc in ARM. And if nothing did... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
