Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
* Andreas Metzler: It is just that an application may not link at the same time against libnettle4 and libgnutls-deb0-28 3.3.15-5. Neither Debian nor afaik any other major distribution supports this kind of complexity in its dependency system (conditional dependencies). And package dependencies are too coarse anyway because this is something that happens on the ELF level. In general, we do not add versioned dependencies to make sure that a fixed version of a dependency affecting a package is installed allong with the latter package. I don't think this case (bug 784009) is all that different. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d1zoihj9@mid.deneb.enyo.de
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Sun, Jun 14, 2015 at 06:43:33PM +0200, Marc Haber wrote: btw, please read up on bug severities. I consider filing this bug as grave quite short of being offensive. If you're genuinely offended by a bug submitter's choice of severity, it's time to take a step back from the computer and get a cup of tea. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150618130738.gb21...@chew.redmars.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Lefevre vinc...@vinc17.net writes: On 2015-06-16 09:12:36 -0700, Russ Allbery wrote: There are a lot of really complex things you can do with versioning and cases where that version number is meaningful, but for the vast majority of libraries, I recommend not worrying about it and just always using some simple transform of the SONAME as the version for all symbols in the library. When you bump the SONAME, bump all the symbol versions. When you introduce a new symbol, use the SONAME as the symbol version. This is not strictly correct in that the symbol version doesn't correspond to a specific API (you're adding new symbols with the same symbol version as old symbols), but most of the functionality you lose is just meaningful error messages when running new binaries against too-old versions of the shared library. And it's way simpler to implement. But can this be detected so that a versioned dependency of the shared library can *automatically* be added when the binary packages are generated, avoiding this problem? I'm not sure what this you're referring to. If you mean detecting that you have newer binaries that require a new version of the shared library, and thus the shared library needs to be upgraded, yes, absolutely. Debian solved this problem years and years ago. That's what you're fixing by bumping the version in dh_makeshlibs in the shared library package: signaling that binary packages should have a tigher versioned dependency. debian/symbols does this in an even more sophisticated way. Just in case, by this, you meant the whole problem of shared library upgrades where you *don't* have symbol versions, here's the long-winded explanation for why you need symbol versions and package dependencies don't cut it: It is nearly impossible to solve this problem with package dependencies. Shared library symbol versioning is required to solve the problem properly and without painstaking and very fragile manual work. This is because the problem is not with direct dependencies on a shared library, but rather with indirect dependencies. What happens is that you have some library -- call it liblow1 -- and you have two other libraries that use it -- call them libfoo1 and libbar1. liblow1 does not have symbol versioning. An incompatible liblow2 is released. The user upgrades the system such that libfoo1 is rebuilt against liblow2, but libbar1 is not. Now, some application, app, which is linked against both libfoo1 and libbar1, is started. What happens is that calls to the functions in liblow1 and liblow2 go to one of the two implementations semi-randomly, and one of either libfoo1 or libbar1 is going to break horribly, usually in some very subtle and awful way. There are a bunch of ELF tricks that you can try to do to minimize this, but none of them are 100% effective. However, symbol versioning is 100% effective, since then libfoo1 and libbar1 are linked against specific versioned symbols, there are no symbol conflicts between liblow1 and liblow2, and both get loaded into memory, both are used appropriately, and app works. To try to solve this with dependencies, you have to make liblow2 conflict with liblow1. But this completely breaks shared library upgrades, since now you have to upgrade every program linked to liblow in lockstep, even if there's no risk for that application of loading two versions at the same time, because you can't have both shared libraries on the system at the same time. It also wipes out our dependency resolver, because there are too many conflicts to find a good solution. Alternately, you can do what we're trying to do here, which is add a complex mess of Breaks and Conflicts to all the various consumers of liblow1 and hope that you caught them all. Spoiler: you never catch them all. Particularly since some of them are user programs that aren't even part of the distribution. Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vbelye4v@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery r...@debian.org: Vincent Lefevre vinc...@vinc17.net Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. The problem is rather that the package dependency system doesn't look at specific package dependency trees to find conflict between liblow1 and liblow2. Instead it always does this globally. That problem is solvable. But you just but the burden on upstreams again. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/25719340-bf04-4aa0-a69f-38c4c19d5...@hendrik-sattler.de
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hendrik Sattler p...@hendrik-sattler.de writes: Am 18. Juni 2015 03:54:56 MESZ, schrieb Russ Allbery r...@debian.org: Shared library symbol versioning makes the problem go away. Package dependencies try to solve the problem at the wrong level. The problem is rather that the package dependency system doesn't look at specific package dependency trees to find conflict between liblow1 and liblow2. Instead it always does this globally. That problem is solvable. You missed the part of my message (which you snipped) where I specifically dealt with this. You cannot make liblow1 and liblow2 conflict without causing tons of other problems, such as preventing partial upgrades and making upgrade solutions infeasible. We want to support coinstallation of different SONAMEs of shared libraries and partial upgrades. These are major, important features for both our users and for our release and library transition process. But you just but the burden on upstreams again. We can add symbol versioning in the Debian packaging even if it's not done upstream. We do that already for some libraries. It's obviously better to do it upstream, though, so that different distributions use the same versioning. It sounds like you're upset about my conclusion for some reason. You're certainly entitled to be upset, but your upsetness is not persuasive to anyone other than you. If you want to effectively argue with conclusion, you're going to have to address my rather extended explanation for why this is the best solution. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv5py680@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-16 09:12:36 -0700, Russ Allbery wrote: There are a lot of really complex things you can do with versioning and cases where that version number is meaningful, but for the vast majority of libraries, I recommend not worrying about it and just always using some simple transform of the SONAME as the version for all symbols in the library. When you bump the SONAME, bump all the symbol versions. When you introduce a new symbol, use the SONAME as the symbol version. This is not strictly correct in that the symbol version doesn't correspond to a specific API (you're adding new symbols with the same symbol version as old symbols), but most of the functionality you lose is just meaningful error messages when running new binaries against too-old versions of the shared library. And it's way simpler to implement. But can this be detected so that a versioned dependency of the shared library can *automatically* be added when the binary packages are generated, avoiding this problem? -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150617065734.ga11...@xvii.vinc17.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hi! On Tue, 2015-06-16 at 09:18:34 +0200, Vincent Bernat wrote: There is not a lot of documentation about how to handle that from an upstream point of view. There is the info page (section VERSION) of ld about -version-script. That's true, there's lots of information spread all over the place, that is either too detailed/deep, or too vague. For example there is also: http://www.akkadia.org/drepper/symbol-versioning http://www.akkadia.org/drepper/goodpractice.pdf http://www.akkadia.org/drepper/dsohowto.pdf In any case, barring better documentation or guides, using example implementations simpler than glibc might be useful to people. So I offer libbsd, but I'm sure there are many others. We could perhaps even create a wiki page listing some of those pointers. libbsd for example exposes setproctitle() with different versions. How a library should transition from non-versioned symbols (use of -version-info only) to versioned symbols? You just switch it, code compiled against the new version will require at least the version switching to versioned symbols, code compiled against an older version will keep working with both. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616135050.ga18...@gaara.hadrons.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
❦ 16 juin 2015 15:50 +0200, Guillem Jover guil...@debian.org : In any case, barring better documentation or guides, using example implementations simpler than glibc might be useful to people. So I offer libbsd, but I'm sure there are many others. We could perhaps even create a wiki page listing some of those pointers. libbsd for example exposes setproctitle() with different versions. Yes, a simple example is great too and libbsd seems fine for that. How a library should transition from non-versioned symbols (use of -version-info only) to versioned symbols? You just switch it, code compiled against the new version will require at least the version switching to versioned symbols, code compiled against an older version will keep working with both. In libbsd, I see that you started with LIBBSD_0.0. Does this mean libbsd has always used symbol versioning? Otherwise, the start point would be to use the previous SONAME (computed from the previous -version-info), right? -- Treat end of file conditions in a uniform manner. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-15 18:56:47 +0200, Andreas Metzler wrote: Vincent Lefevre vinc...@vinc17.net wrote: [...] (Bug 788710 shouldn't have been closed, but changed to something like what bug 788735 says.) [...] No, it should not have been filed, since the same bug had been filed 5 times already. No, this is *not* the same bug that was filed. The bugs that were filed are claimed to be fixed in gnutls28/3.3.15-5, while the crash I got was in gnutls28/3.3.15-6: After upgrading libgnutls-deb0-28 from 3.3.14-2 to 3.3.15-6: So, obviously, you got this wrong. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616144812.gb32...@ypig.lip.ens-lyon.fr
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Bernat ber...@debian.org writes: In libbsd, I see that you started with LIBBSD_0.0. Does this mean libbsd has always used symbol versioning? Otherwise, the start point would be to use the previous SONAME (computed from the previous -version-info), right? There are a lot of really complex things you can do with versioning and cases where that version number is meaningful, but for the vast majority of libraries, I recommend not worrying about it and just always using some simple transform of the SONAME as the version for all symbols in the library. When you bump the SONAME, bump all the symbol versions. When you introduce a new symbol, use the SONAME as the symbol version. This is not strictly correct in that the symbol version doesn't correspond to a specific API (you're adding new symbols with the same symbol version as old symbols), but most of the functionality you lose is just meaningful error messages when running new binaries against too-old versions of the shared library. And it's way simpler to implement. I've used the fully correct symbol versioning on some projects and found that I was generally incrementing the symbol version on just about everything when I changed SONAMEs anyway, and could have saved a lot of maintenance overhead by just using this approach. I wasn't getting much benefit from being more precise. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d20vaayz@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-15 20:52:25 +0200, Magnus Holmgren wrote: But libgnutls-deb0-28 technically doesn't break libnettle4, nor does libnettle6. It's only certain combinations of three or more packages that are broken, something the dependency system can't handle. Then either the dependency system should be fixed to handle that, or there should be a workaround. Declaring libnettle6 to break rdeps known to be built against libnettle4 might be the best option but then again there could be versions in backports with lower version numbers yet built against libnettle6. Right? Or libnettle6 could be declared to break libnettle4 to make sure that programs don't link to both at the same time. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616145826.gc32...@ypig.lip.ens-lyon.fr
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Guillem Jover wrote: In any case, barring better documentation or guides, using example implementations simpler than glibc might be useful to people. So I offer libbsd, but I'm sure there are many others. We could perhaps even create a wiki page listing some of those pointers. libabc is a great example: http://0pointer.de/blog/projects/libabc.html -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150616152711.ga11...@mycre.ws
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Lefevre vinc...@vinc17.net wrote: On 2015-06-15 18:56:47 +0200, Andreas Metzler wrote: [...] No, it should not have been filed, since the same bug had been filed 5 times already. No, this is *not* the same bug that was filed. The bugs that were filed are claimed to be fixed in gnutls28/3.3.15-5, while the crash I got was in gnutls28/3.3.15-6: After upgrading libgnutls-deb0-28 from 3.3.14-2 to 3.3.15-6: So, obviously, you got this wrong. If you are experiencing an issue that looks identical to an issue filed 5 times before but has been marked as fixed in the previous upload the correct response is not to simply file another bug, but to actually look at the other issue, try to understand what happened, especially whether it might be the same issue. And if it is the same issue and might not have been correctly marked as fixed you shjould not open another bug report but try to get the previous one reopened. cu And- last message to this thread -reas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5q265c-l62@argenau.downhill.at.eu.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
❦ 15 juin 2015 20:20 -0700, Russ Allbery r...@debian.org : To avoid confusing myself further, Russ and Neil, are you both talking about the debian/symbols files? I thought Russ might have been talking about versioned symbols at DSO level (e.g. symbol@LOW0 vs symbol@LOW1). I'm pretty sure Russ was indeed talking about versioned symbols at DSO level. Having debian/symbols doesn't solve the issue at hand here. Yup, I was talking about the DSO level. debian/symbols doesn't help (although it's certainly nice for other things). There is not a lot of documentation about how to handle that from an upstream point of view. There is the info page (section VERSION) of ld about -version-script. How a library should transition from non-versioned symbols (use of -version-info only) to versioned symbols? -- I dote on his very absence. -- William Shakespeare, The Merchant of Venice signature.asc Description: PGP signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Niels Thykier ni...@thykier.net (2015-06-15): On 2015-06-15 08:04, Neil Williams wrote: On Sun, 14 Jun 2015 13:26:26 -0700 Russ Allbery r...@debian.org wrote: Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. With the proviso that ignoring/fudging a SONAME change to avoid this step is an RC bug. A SONAME change going through NEW which doesn't include symbol versioning should be a reject. The work to generate the symbols has already been done but needs a new maintainer (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543640). That would need to be fixed first. [...] To avoid confusing myself further, Russ and Neil, are you both talking about the debian/symbols files? I thought Russ might have been talking about versioned symbols at DSO level (e.g. symbol@LOW0 vs symbol@LOW1). I'm pretty sure Russ was indeed talking about versioned symbols at DSO level. Having debian/symbols doesn't solve the issue at hand here. Mraw, KiBi. signature.asc Description: Digital signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Sun, Jun 14, 2015, at 17:26, Russ Allbery wrote: Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. I know this is a ton of work for a lot of edge packages where the upstream maintainers are building shared libraries without really understanding how they work, but it's so hard to properly manage library upgrades without symbol versioning. I'd second that requirement, provided that we come up with helpful documentation that we can point upstream to, teaching them the ins and outs of proper library ABI management using *easy* symbol versioning (i.e. symbol version based on the soname: it really doesn't need to be the advanced stuff done by the libc for the vast majority of the libraries). This specific breakage anti-pattern has been breaking Linux systems for nearly two decades. Another related anti-pattern is caused by globally switchable behavior in liblow0: library-wide behavior must be context based, otherwise you can have the application asking for one setting, and underyling libraries wanting other (possibly diverse) settings. Some of us still remember the damage caused by this anti-pattern in Cyrus SASL, many years ago. -- 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 de Moraes Holschuh h...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1434377533.1003243.295901177.57632...@webmail.messagingengine.com
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Cyril Brulebois k...@debian.org writes: Niels Thykier ni...@thykier.net (2015-06-15): To avoid confusing myself further, Russ and Neil, are you both talking about the debian/symbols files? I thought Russ might have been talking about versioned symbols at DSO level (e.g. symbol@LOW0 vs symbol@LOW1). I'm pretty sure Russ was indeed talking about versioned symbols at DSO level. Having debian/symbols doesn't solve the issue at hand here. Yup, I was talking about the DSO level. debian/symbols doesn't help (although it's certainly nice for other things). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k2v4nxu2@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Felipe Sateler fsateler at debian.org writes: On Mon, 15 Jun 2015 19:15:13 +0200, Andreas Metzler wrote: Vincent Lefevre vincent at vinc17.net wrote: Is the Debian dependency system broken? [...] No, but there is no way to *correctly* handle the problem with the automatic depency mechanism. It is possible to use in some manual kludge, [...] libnettle4 and libgnutls-deb0-28 3.3.15-5. Neither Debian nor afaik any other major distribution supports this kind of complexity in its dependency system (conditional dependencies). You can, as hinted in the bug report, Breaks all packages depending on libnettle4 and libgnutls-deb0-28 ( the version at which they switch to libnettle6). [...] That is neither correct, nor a good solution. - As Magnus noted this would make backports of nettle-rdeps impossible. FWIW I will add Conflicts against the nettle 2.7 library package in the next GnuTLS unstable upload. Change is already in GIT. cu Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20150616t073149-...@post.gmane.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Mon, 15 Jun 2015 19:15:13 +0200, Andreas Metzler wrote: Vincent Lefevre vinc...@vinc17.net wrote: Is the Debian dependency system broken? [...] No, but there is no way to *correctly* handle the problem with the automatic depency mechanism. It is possible to use in some manual kludge, but not a correct one. libgnutls-deb0-28 3.3.15-5 does not break or conflict with libnettle4. An application just using libnettle4 will continue to work no matter whether gnutls is rebuilt against libnettle6. It is just that an application may not link at the same time against libnettle4 and libgnutls-deb0-28 3.3.15-5. Neither Debian nor afaik any other major distribution supports this kind of complexity in its dependency system (conditional dependencies). You can, as hinted in the bug report, Breaks all packages depending on libnettle4 and libgnutls-deb0-28 ( the version at which they switch to libnettle6). Simply Breaking libnettle4 is more restrictive, but it will avoid the segfaults. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mln7e0$ft$1...@ger.gmane.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
söndagen den 14 juni 2015 22.38.28 skrev Vincent Lefevre: Well, there are two things that one wants to avoid: 1. Upgrading libgnutls-deb0-28 to a version using libnettle6 without upgrading the packages that depend on libgnutls-deb0-28 and use libnettle4. This is the problem I've mentioned here. And there's now the following bug reported by Felipe Sateler: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788735 But libgnutls-deb0-28 technically doesn't break libnettle4, nor does libnettle6. It's only certain combinations of three or more packages that are broken, something the dependency system can't handle. Declaring libnettle6 to break rdeps known to be built against libnettle4 might be the best option but then again there could be versions in backports with lower version numbers yet built against libnettle6. Right? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Lefevre vinc...@vinc17.net wrote: Is the Debian dependency system broken? [...] No, but there is no way to *correctly* handle the problem with the automatic depency mechanism. It is possible to use in some manual kludge, but not a correct one. libgnutls-deb0-28 3.3.15-5 does not break or conflict with libnettle4. An application just using libnettle4 will continue to work no matter whether gnutls is rebuilt against libnettle6. It is just that an application may not link at the same time against libnettle4 and libgnutls-deb0-28 3.3.15-5. Neither Debian nor afaik any other major distribution supports this kind of complexity in its dependency system (conditional dependencies). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/vpd35c-n72@argenau.downhill.at.eu.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Vincent Lefevre vinc...@vinc17.net wrote: [...] (Bug 788710 shouldn't have been closed, but changed to something like what bug 788735 says.) [...] No, it should not have been filed, since the same bug had been filed 5 times already. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dnc35c-i62@argenau.downhill.at.eu.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Sun, 14 Jun 2015 13:26:26 -0700 Russ Allbery r...@debian.org wrote: Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. With the proviso that ignoring/fudging a SONAME change to avoid this step is an RC bug. A SONAME change going through NEW which doesn't include symbol versioning should be a reject. The work to generate the symbols has already been done but needs a new maintainer (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543640). That would need to be fixed first. I know this is a ton of work for a lot of edge packages where the upstream maintainers are building shared libraries without really understanding how they work, but it's so hard to properly manage library upgrades without symbol versioning. Yet these are precisely the packages (and upstreams) which are most in need of such a requirement. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgppkkShkwh1J.pgp Description: OpenPGP digital signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-15 08:04, Neil Williams wrote: On Sun, 14 Jun 2015 13:26:26 -0700 Russ Allbery r...@debian.org wrote: Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. With the proviso that ignoring/fudging a SONAME change to avoid this step is an RC bug. A SONAME change going through NEW which doesn't include symbol versioning should be a reject. The work to generate the symbols has already been done but needs a new maintainer (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543640). That would need to be fixed first. [...] To avoid confusing myself further, Russ and Neil, are you both talking about the debian/symbols files? I thought Russ might have been talking about versioned symbols at DSO level (e.g. symbol@LOW0 vs symbol@LOW1). ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557e6ea2.4090...@thykier.net
Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Normally, a well-designed dependency system should make sure that the user cannot install an incorrect combination of packages (avoiding segmentation faults and internal errors), e.g. during a partial upgrade. But it appears that this is not the case, and users are required to do apt-get (dist-)upgrade and can no longer rely on apt-get install some package to upgrade just the wanted package and dependencies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788710#10 Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614140332.ga...@xvii.vinc17.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 14/06/15 17:19, Felipe Sateler wrote: I think either libgnutls-deb0-28 or libnettle6 should add a Breaks: libnettle4[1], to ensure all related packages are upgraded in lockstep. This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols * binaries linked to libhigh0, but whose only reference to liblow* is via libhigh0, upgrade gracefully * binaries that end up with both liblow0 and liblow1 in their address space crash For instance, in this particular case, libhigh is gnutls and liblow is nettle. The GNOME team sees this every few GNOME release cycles with clutter (which is long-term ABI-stable) and its dependency cogl (which isn't). I'm sure there are plenty more examples. Linking with -Wl,--as-needed and making use of pkg-config's Requires.private mitigates this problem by reducing the number of binaries explicitly linked to both libhigh0 and liblow, but doesn't solve it for anything that does explicitly use liblow functionality. One solution is to give the lower-level library versioned symbols, with at least one unique version per SONAME. That's how libjpeg and libpng avoid breaking lots of GUIs every time they bump SONAME, for instance. Another solution is to add enough Breaks to force a lockstep upgrade, which is how the GNOME team deals with it for clutter/cogl AIUI. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557db0ba.2060...@debian.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Sun, 14 Jun 2015 16:03:32 +0200, Vincent Lefevre wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788710#10 Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). I think either libgnutls-deb0-28 or libnettle6 should add a Breaks: libnettle4[1], to ensure all related packages are upgraded in lockstep. I have filed bug #788735 for this. [1] Maybe it could only break all rdeps of libnettle4 at the appropriate versions, but this is easier. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mlk9i6$ih3$1...@ger.gmane.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On Sun, 14 Jun 2015 16:03:32 +0200, Vincent Lefevre vinc...@vinc17.net wrote: Normally, a well-designed dependency system should make sure that the user cannot install an incorrect combination of packages (avoiding segmentation faults and internal errors), e.g. during a partial upgrade. But it appears that this is not the case, and users are required to do apt-get (dist-)upgrade and can no longer rely on apt-get install some package to upgrade just the wanted package and dependencies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788710#10 Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). So gnutls-deb0-28 needs a versioned dependency on the correct wget version. Is that a problem? btw, please read up on bug severities. I consider filing this bug as grave quite short of being offensive. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1z4b0p-s1...@swivel.zugschlus.de
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hi, Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). well, then, obviously, the dependency on libgnutls-deb0-28 (= 3.3.0) in wget is a bit too optimistic. This could have been prevented by the wget maintainer selecting a more restrictive set ot libgnutls versions, probably just 3.3.0. Then again, you wouldn't expect a library to break ABI between revisions. So this might also be considered a bug in libgnutls or even in its developers. In any case, this is nothing any package dependency system could fix unless told about the situation, because, as noted above, there even is an expressly written rule stating that 3.3.15, being = 3.3.0, is perfectly ok, and that's what apt takes into account, and that's the best it can do. -nik signature.asc Description: OpenPGP digital signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Simon McVittie s...@debian.org wrote: [...] One solution is to give the lower-level library versioned symbols, with at least one unique version per SONAME. That's how libjpeg and libpng avoid breaking lots of GUIs every time they bump SONAME, for instance. [...] FWIW this specific combination should not break again, since the new nettle has versioned symbols. It also should not hit us on the jessie-jessie+1 upgrade, because this will include a GnuTLS soname-bump which automatically enforces a lockstep nettle/gnutls update. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/eqs05c-f0l@argenau.downhill.at.eu.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-14 18:15:33 +0200, Dominik George wrote: Hi, Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). well, then, obviously, the dependency on libgnutls-deb0-28 (= 3.3.0) in wget is a bit too optimistic. This could have been prevented by the wget maintainer selecting a more restrictive set ot libgnutls versions, probably just 3.3.0. Well, there are two things that one wants to avoid: 1. Upgrading libgnutls-deb0-28 to a version using libnettle6 without upgrading the packages that depend on libgnutls-deb0-28 and use libnettle4. This is the problem I've mentioned here. And there's now the following bug reported by Felipe Sateler: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788735 (Bug 788710 shouldn't have been closed, but changed to something like what bug 788735 says.) 2. Upgrading wget to to a version using libnettle6 without upgrading libgnutls-deb0-28 to such a version too. For this point, I agree that the dependency on libgnutls-deb0-28 (= 3.3.0) in wget is too optimistic. That's the following bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787942 BTW, if wget had the correct dependency, I would probably never have seen problem (1). In any case, this is nothing any package dependency system could fix unless told about the situation, because, as noted above, there even is an expressly written rule stating that 3.3.15, being = 3.3.0, is perfectly ok, and that's what apt takes into account, and that's the best it can do. OK, so, that's more a problem with developers who close bugs without fixing the dependencies. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614203828.gb20...@xvii.vinc17.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
On 2015-06-14 18:43:33 +0200, Marc Haber wrote: On Sun, 14 Jun 2015 16:03:32 +0200, Vincent Lefevre vinc...@vinc17.net wrote: Normally, a well-designed dependency system should make sure that the user cannot install an incorrect combination of packages (avoiding segmentation faults and internal errors), e.g. during a partial upgrade. But it appears that this is not the case, and users are required to do apt-get (dist-)upgrade and can no longer rely on apt-get install some package to upgrade just the wanted package and dependencies: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788710#10 Note that the problem still occurs on an available set of packages: just start with a Debian/stable system (jessie) and upgrade libgnutls-deb0-28 to unstable (no dependencies/conflicts will yield an upgrade of wget, which will occasionally segfault). So gnutls-deb0-28 needs a versioned dependency on the correct wget version. Is that a problem? The bug was closed without fixing the dependency (gnutls-deb0-28 should actually break libnettle4). btw, please read up on bug severities. I consider filing this bug as grave quite short of being offensive. Well, I got segfaults and internal errors on various websites. A package that is broken at this point is almost completely unusable, so that it deserves a grave bug. Note that I hadn't thought that this was a dependency problem precisely because libgnutls-deb0-28 allowed such a package combination. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614201809.ga20...@xvii.vinc17.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Simon McVittie s...@debian.org writes: This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols And this point is the root of the problem. When I'm in a particular tilting at windmills mood, I think we should just stop accepting new shared libraries in Debian that don't use symbol versioning, and make adding symbol versioning mandatory the next time the SONAME changes. I know this is a ton of work for a lot of edge packages where the upstream maintainers are building shared libraries without really understanding how they work, but it's so hard to properly manage library upgrades without symbol versioning. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4jm2g0d@hope.eyrie.org
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hi Siomn, On Sun, Jun 14, 2015 at 05:50:02PM +0100, Simon McVittie wrote: On 14/06/15 17:19, Felipe Sateler wrote: I think either libgnutls-deb0-28 or libnettle6 should add a Breaks: libnettle4[1], to ensure all related packages are upgraded in lockstep. This is a recurring (anti-)pattern: * an ABI-stable, high-level library, say libhigh0, links to a lower-level library, say liblow0 * we have an ABI transition from liblow0 to liblow1 * liblow0 and liblow1 do not both have versioned symbols * binaries linked to libhigh0, but whose only reference to liblow* is via libhigh0, upgrade gracefully * binaries that end up with both liblow0 and liblow1 in their address space crash For instance, in this particular case, libhigh is gnutls and liblow is nettle. The GNOME team sees this every few GNOME release cycles with clutter (which is long-term ABI-stable) and its dependency cogl (which isn't). I'm sure there are plenty more examples. Linking with -Wl,--as-needed and making use of pkg-config's Requires.private mitigates this problem by reducing the number of binaries explicitly linked to both libhigh0 and liblow, but doesn't solve it for anything that does explicitly use liblow functionality. One solution is to give the lower-level library versioned symbols, with at least one unique version per SONAME. That's how libjpeg and libpng avoid breaking lots of GUIs every time they bump SONAME, for instance. Another solution is to add enough Breaks to force a lockstep upgrade, which is how the GNOME team deals with it for clutter/cogl AIUI. Hrm, you're not coming to DebConf15, right? I think a talk like Best Practises for Debian Library Packaging would be well-received, I am not sure we had something like this decade... (the CfP would be open for another 24 hours) Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150614205538.ga12...@raptor.chemicalconnection.dyndns.org
