On Sat, Dec 14, 2002 at 04:00:00PM -0600, Rob Browning wrote: > Note: this particular case is specific to guile, but I suspect the > broader issue applies for many other packages, and the particular > problem here is relevant to several debian packages, including the > example below, the gwrapguile package. It does, and it's a perennial problem. > so far so good, no let's presume the gwrap maintainer wants to rebuild > his package against the new guile. So he rebuilds gwrap and produces: > > libgwrap-glib???: (provides libgwrap-glib.so.???) (depends libguile.so.12) > > The question is what goes where the ??? is above? If we pick "1", for > the soname, then as soon as the gwrap maintainer uploads the new gwrap > packages and they're installed, both gnucash and some-other-app are > broken, even though all of their dependencies are still satisfied. Within the SONAME model, which specifies a single monotonically incrementing version for every shared object, the only solution is to have upstream explicitly specify that libgwrap-glib.so.a is to be linked against libguile.so.x, and libgwrap-glib.so.b is to be linked against libguile.so.y, with specific versions. Ideally the build system would enforce this (autoconf macro, anyone?). This has to be consistant across all distributions if binaries are to be compatible. Note that this only applies in the case where data types inherited from libguile form a part of the exported interface of libgwrap-glib. In the case of exported *functions*, they can be handled by versioned symbols in the linker. The problem is in the case of types, which cannot be versioned (this is a limitation of C in its current form, along with most other languages; there are workarounds, but that's another story). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK
Attachment:
pgp1qnE6lT7Mc.pgp
Description: PGP signature