Re: Improving dependencies on shared libraries
On Mon, Jun 04, 2007, Wouter Verhelst wrote: On Sun, Jun 03, 2007 at 01:30:39PM +0200, Mike Hommey wrote: On Sun, Jun 03, 2007 at 12:37:08PM +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. Miss one and you create a whole load of bugs. As much bugs as when you don't bump the shlibs... Most library packages use dh_makeshlibs -V anyway... If you miss symbols, I suppose the tool gets to decide how to handle it, and would probably default to something sane; this means we would get dh_makeshlibs -V per-symbol instead of per-library in this case; smaller pain than dh_makeshlibs -V. dh_makeshlibs -V should be kept for young libraries: http://lists.debian.org/debian-devel/2004/08/thrd3.html#01359 -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. Miss one and you create a whole load of bugs. It also presumes the library maintainer knows enough about libraries to be able to handle this type of thing, which I do not think is a safe presumption. However it might well be some form of micro-management that you don't want to have to deal with. And it can't be handled automatically. How frequently do we encounter this kind of extension of the ABI ? Most libraries have a bunch of them on every ABI update. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sun, Jun 03, 2007 at 12:37:08PM +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. Miss one and you create a whole load of bugs. As much bugs as when you don't bump the shlibs... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sun, 03 Jun 2007, Wouter Verhelst wrote: On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. Miss one and you create a whole load of bugs. It also presumes the library maintainer knows enough about libraries to be able to handle this type of thing, which I do not think is a safe presumption. Pierre explained that a sane library maintainer could/would use a new version associated to the symbol even the ABI hasn't changed so that any application linked against the newer version get to effectively depend on the new version. I really think that the benefits outweigh those problems by an order of magnitude. And as Mike said, it's not worse than forgetting to bump the shlibs currently. On the contrary, with my mecanism if a new symbol appear it's automatically associated to the new release. Thus it's no more possible to miss new symbols and forget to bump the shlibs. I really think that on the whole, it will be way better than the current situation. I have a first version of the code implementing most of this and I'm going to send that info in a separate mail RSN. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
Le dimanche 03 juin 2007 à 19:32 +0200, Raphael Hertzog a écrit : Pierre explained that a sane library maintainer could/would use a new version associated to the symbol even the ABI hasn't changed so that any application linked against the newer version get to effectively depend on the new version. I'm afraid we could count the number of libraries that use a per-symbol versioning scheme with a single hand. I really think that the benefits outweigh those problems by an order of magnitude. And as Mike said, it's not worse than forgetting to bump the shlibs currently. Except that you are asking for something much more complicated. Furthermore, we currently have dh_makeshlibs -V for upstreams who add to their ABI in almost each new release. On the contrary, with my mecanism if a new symbol appear it's automatically associated to the new release. Thus it's no more possible to miss new symbols and forget to bump the shlibs. I really think that on the whole, it will be way better than the current situation. It will surely be better for a majority of packages, and it is going to completely break a minority. It is not possible to rely on maintainers who don't really understand all the ways an ABI can change to tell whether this or that symbol has changed. I wouldn't trust myself to do that over a long time for all my own packages, at least. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
On Sun, Jun 03, 2007 at 07:52:40PM +0200, Josselin Mouette wrote: Le dimanche 03 juin 2007 à 19:32 +0200, Raphael Hertzog a écrit : Pierre explained that a sane library maintainer could/would use a new version associated to the symbol even the ABI hasn't changed so that any application linked against the newer version get to effectively depend on the new version. I'm afraid we could count the number of libraries that use a per-symbol versioning scheme with a single hand. Of a guy that had many fingers amputated. On the contrary, with my mecanism if a new symbol appear it's automatically associated to the new release. Thus it's no more possible to miss new symbols and forget to bump the shlibs. I really think that on the whole, it will be way better than the current situation. It will surely be better for a majority of packages, and it is going to completely break a minority. It is not possible to rely on maintainers who don't really understand all the ways an ABI can change to tell whether this or that symbol has changed. I wouldn't trust myself to do that over a long time for all my own packages, at least. FWIW I don't really think it'll break a lot of one, and this minority could be flagged not-for-buxy's-tool. What worries me more is the big amount of let's say (completely at random) C++ libraries that do not use symbols visibility, hence exposing myriad of non exported symbols, which will create new shlib bumps for ... nothing. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpq8PavhzxpP.pgp Description: PGP signature
Re: Improving dependencies on shared libraries
On Sun, Jun 03, 2007 at 10:51:24PM +0200, Pierre Habouzit [EMAIL PROTECTED] wrote: On Sun, Jun 03, 2007 at 07:52:40PM +0200, Josselin Mouette wrote: Le dimanche 03 juin 2007 à 19:32 +0200, Raphael Hertzog a écrit : Pierre explained that a sane library maintainer could/would use a new version associated to the symbol even the ABI hasn't changed so that any application linked against the newer version get to effectively depend on the new version. I'm afraid we could count the number of libraries that use a per-symbol versioning scheme with a single hand. Of a guy that had many fingers amputated. On the contrary, with my mecanism if a new symbol appear it's automatically associated to the new release. Thus it's no more possible to miss new symbols and forget to bump the shlibs. I really think that on the whole, it will be way better than the current situation. It will surely be better for a majority of packages, and it is going to completely break a minority. It is not possible to rely on maintainers who don't really understand all the ways an ABI can change to tell whether this or that symbol has changed. I wouldn't trust myself to do that over a long time for all my own packages, at least. FWIW I don't really think it'll break a lot of one, and this minority could be flagged not-for-buxy's-tool. What worries me more is the big amount of let's say (completely at random) C++ libraries that do not use symbols visibility, hence exposing myriad of non exported symbols, which will create new shlib bumps for ... nothing. Actually, the bump would only occur if the symbol get used... which wouldn't be a problem. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sun, Jun 03, 2007 at 01:30:39PM +0200, Mike Hommey wrote: On Sun, Jun 03, 2007 at 12:37:08PM +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. Miss one and you create a whole load of bugs. As much bugs as when you don't bump the shlibs... Most library packages use dh_makeshlibs -V anyway... -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, May 26, 2007 at 04:04:10PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Sat, May 26, 2007 at 10:09:44PM +0200, Josselin Mouette wrote: Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit : Hello, in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. Some research Scott James Remnant did back in the woody days indicated that with a more finely-grained shlibs implementation, the majority of packages could run fine against glibc 2.0. No such luck with lenny due to the change of symbol hash tables which now require a recent ld.so to parse, but it'll probably take more than a full release cycle to get this implemented and widely adopted anyway, so... When is it supposed to happen or have happened ? Because I just tried installing libxml2 and libxml2-utils from sid on an etch system, with dpkg --force-depends, and xmllint works perfectly fine... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
Raphael Hertzog [EMAIL PROTECTED] wrote: in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. The system should have historical knowledges of symbols exported by libraries. Then when generating dependencies on an given package, it should check which symbols are used and what minimal version of the library provided them. Please find a sort of specification in the wiki: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps Please check it out and share your comments. I'm not an expert of libraries and I may have missed some important points. [...] Hello, rpm has something like that, it relies on a specific way of symbol versioning. - Newly added symbols get a different version, and you can tell whether a program is using new symbols by checking Version References: in objdump -p's output. rpm then generates dependencies on libfoo.so.12(BLAH_1) and (if necessary) /additionally/ libfoo.so.12(BLAH_2). libasound is library that implements this. This does not address changed symbol hashing at all and requires upstream to keep books on added symbols in the symbol versioning script. Which is why I do not think it is going to see widespread use. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sun, 27 May 2007, Mike Hommey wrote: Some research Scott James Remnant did back in the woody days indicated that with a more finely-grained shlibs implementation, the majority of packages could run fine against glibc 2.0. No such luck with lenny due to the change of symbol hash tables which now require a recent ld.so to parse, but it'll probably take more than a full release cycle to get this implemented and widely adopted anyway, so... When is it supposed to happen or have happened ? Because I just tried installing libxml2 and libxml2-utils from sid on an etch system, with dpkg --force-depends, and xmllint works perfectly fine... The change hash-style=gnu happened with gcc-4.1 4.1.2-5 although the version -7 changes this again to hash-style=both. In the mean time, libc6 2.5-5 bumped its shlibs to avoid problems with packages compiled with a gcc using hash-style=gnu. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421790 So maybe the problem affects only some architectures which do not support hash-style=both? What arches do not support this? For me it would seem wise to keep hash-style=both for the entire lenny cycle and drop it during the lenny+1 cycle to have a smooth transition on this aspect. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sun, May 27, 2007 at 09:56:13AM +0200, Raphael Hertzog wrote: On Sun, 27 May 2007, Mike Hommey wrote: Some research Scott James Remnant did back in the woody days indicated that with a more finely-grained shlibs implementation, the majority of packages could run fine against glibc 2.0. No such luck with lenny due to the change of symbol hash tables which now require a recent ld.so to parse, but it'll probably take more than a full release cycle to get this implemented and widely adopted anyway, so... When is it supposed to happen or have happened ? Because I just tried installing libxml2 and libxml2-utils from sid on an etch system, with dpkg --force-depends, and xmllint works perfectly fine... The change hash-style=gnu happened with gcc-4.1 4.1.2-5 although the version -7 changes this again to hash-style=both. In the mean time, libc6 2.5-5 bumped its shlibs to avoid problems with packages compiled with a gcc using hash-style=gnu. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421790 So maybe the problem affects only some architectures which do not support hash-style=both? What arches do not support this? For me it would seem wise to keep hash-style=both for the entire lenny cycle and drop it during the lenny+1 cycle to have a smooth transition on this aspect. No the problem is worse than that, ld.so has supported both styles for hashing for years, so it's not really a matter at *run*-time. Though, the rest of the toolchain (binutils in particular) did not, and isn't able to grok hash-style=gnu in etch. Hence e.g. if libxml2 has been build with -hash-style=gnu you won't be able to link any program against it. The glibc shlibs is a very loosy and convoluted way to make sure that the toolchain is recent enough, because the change was uncoordinated. Though with --hash-style=both this should indeed limit the damages. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoRjkiOqjkq.pgp Description: PGP signature
Re: Improving dependencies on shared libraries
Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit :
in the list of things that we can do to make it more easy to backport
packages, there's one important item: have a finer-grained system for
generating dependencies on shared libraries. The system should have
historical knowledges of symbols exported by libraries. Then when
generating dependencies on an given package, it should check which symbols
are used and what minimal version of the library provided them.
This is not going to work. Checking that symbols are present in a
version does not guarantee they provide the required ABI.
Let's consider the following code for libfoo 1.1:
enum {
FOO_MODE_A,
FOO_MODE_B
}
int libfoo_render(foo_t *f, uint32 mode) {
switch(mode) {
case FOO_MODE_A:
do_something(f);
break;
case FOO_MODE_B:
do_something_else(f);
break;
default:
warn_noisily(mode);
abort();
}
}
If libfoo 1.2 adds a new value in the enum (FOO_MODE_C), a new binary
built against it may use it, and in this case will need version 1.2.
However there is no obvious way by looking at the binary to tell whether
this is the case. If you just look at when the symbol was introduced,
you will just make the binary depend on version 1.2.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
Le samedi 26 mai 2007 à 21:55 +0200, Josselin Mouette a écrit : If libfoo 1.2 adds a new value in the enum (FOO_MODE_C), a new binary built against it may use it, and in this case will need version 1.2. However there is no obvious way by looking at the binary to tell whether this is the case. If you just look at when the symbol was introduced, you will just make the binary depend on version 1.2. ^^^ This is 1.1, of course. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit : Hello, in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
On Sat, 26 May 2007, Josselin Mouette wrote: Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit : in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. The system should have historical knowledges of symbols exported by libraries. Then when generating dependencies on an given package, it should check which symbols are used and what minimal version of the library provided them. This is not going to work. Checking that symbols are present in a version does not guarantee they provide the required ABI. If the ABI changes, the soname changes. I store the information of symbols for a given soname. So it should work. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, 26 May 2007, Josselin Mouette wrote: Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit : Hello, in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. If you can reuse most of the build-deps from testing instead of having to recompile the build-deps too, it helps a lot. If you can reuse a package from testing in stable without recompiling, it also helps. :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
Le samedi 26 mai 2007 à 22:35 +0200, Raphael Hertzog a écrit : Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. If you can reuse most of the build-deps from testing instead of having to recompile the build-deps too, it helps a lot. The build-deps also need to be rebuilt against the stable libc. If you can reuse a package from testing in stable without recompiling, it also helps. :-) That would not happen if there is a major libc upgrade between stable and testing. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
Le samedi 26 mai 2007 à 22:34 +0200, Raphael Hertzog a écrit : This is not going to work. Checking that symbols are present in a version does not guarantee they provide the required ABI. If the ABI changes, the soname changes. I store the information of symbols for a given soname. So it should work. The soname only changes if the ABI becomes incompatible. If the ABI is extended, the soname doesn't change. The example I showed doesn't require a soname change. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Improving dependencies on shared libraries
On Sat, 26 May 2007, Josselin Mouette wrote: Le samedi 26 mai 2007 à 22:34 +0200, Raphael Hertzog a écrit : This is not going to work. Checking that symbols are present in a version does not guarantee they provide the required ABI. If the ABI changes, the soname changes. I store the information of symbols for a given soname. So it should work. The soname only changes if the ABI becomes incompatible. If the ABI is extended, the soname doesn't change. The example I showed doesn't require a soname change. Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. However it might well be some form of micro-management that you don't want to have to deal with. And it can't be handled automatically. How frequently do we encounter this kind of extension of the ABI ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, May 26, 2007 at 11:02:37PM +0200, Raphael Hertzog wrote: On Sat, 26 May 2007, Josselin Mouette wrote: Le samedi 26 mai 2007 à 22:34 +0200, Raphael Hertzog a écrit : This is not going to work. Checking that symbols are present in a version does not guarantee they provide the required ABI. If the ABI changes, the soname changes. I store the information of symbols for a given soname. So it should work. The soname only changes if the ABI becomes incompatible. If the ABI is extended, the soname doesn't change. The example I showed doesn't require a soname change. Right, I read your message too quickly, sorry. However the maintainer can change the symbols file in his package and update the dependency associated to this symbol and make sure that a binary using this symbol will depend on the version used to build the package. However it might well be some form of micro-management that you don't want to have to deal with. And it can't be handled automatically. How frequently do we encounter this kind of extension of the ABI ? For skilled upstreams yes it happens. Breaking ABI or doing backward incompatbile changes suck, and clever upstream that know about libraries do it all the time (Okay that left us only maybe 10 or 15 upstreams match the criterium). Though, upstreams doing this could also I'd say use symbol versionning and bump the version of this symbol if it behaviour changed, so that the binary couldn't be used on an earlier version of the library by mistake, depends on what this extension of the API really does. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpONJFXP09je.pgp Description: PGP signature
Re: Improving dependencies on shared libraries
On Sat, 26 May 2007, Josselin Mouette wrote: If you can reuse most of the build-deps from testing instead of having to recompile the build-deps too, it helps a lot. The build-deps also need to be rebuilt against the stable libc. If you can reuse a package from testing in stable without recompiling, it also helps. :-) That would not happen if there is a major libc upgrade between stable and testing. Why ? In lenny/sid, it's effectively the case because symbol hashing changed and ld.so of etch is not able to load libraries using the new hashing. However, in the general case, the soname of the libc hasn't changed for a long time and most applications only use functions which have been available for a very long time. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, May 26, 2007 at 10:47:10PM +0200, Josselin Mouette [EMAIL PROTECTED] wrote: Le samedi 26 mai 2007 à 22:35 +0200, Raphael Hertzog a écrit : Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. If you can reuse most of the build-deps from testing instead of having to recompile the build-deps too, it helps a lot. The build-deps also need to be rebuilt against the stable libc. If you can reuse a package from testing in stable without recompiling, it also helps. :-) That would not happen if there is a major libc upgrade between stable and testing. This is not true. Look at libxml2, for example. The higher symbol version of libc it needs is 2.3.2, while it was built against (and now depends on) libc 2.5. The libxml2 package currently in sid could perfectly be used on etch if its dependencies were not so tight. And a lot of packages are in the same situation, not only because of the libc. The same applies to libxml2 rdepends, by the way. Most don't use the symbols that have been added in the latest versions, but still depend on the latest because it has new symbols which means I have to bump the shlibs. So technically, most packages built against libxml2 in sid would be fine with the version of libxml2 in sarge ! (modulo bugs, obviously) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Improving dependencies on shared libraries
On Sat, May 26, 2007 at 10:09:44PM +0200, Josselin Mouette wrote: Le samedi 26 mai 2007 à 21:06 +0200, Raphael Hertzog a écrit : Hello, in the list of things that we can do to make it more easy to backport packages, there's one important item: have a finer-grained system for generating dependencies on shared libraries. Another important point: such a system would help a lot to obtain lower testing migration times, but it would not help backports at all, since you still have to rebuild the package against the stable libc. Some research Scott James Remnant did back in the woody days indicated that with a more finely-grained shlibs implementation, the majority of packages could run fine against glibc 2.0. No such luck with lenny due to the change of symbol hash tables which now require a recent ld.so to parse, but it'll probably take more than a full release cycle to get this implemented and widely adopted anyway, so... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
