[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: library versioning: making upstream policy, need debian evaluation.



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: pgp5er5E36HFt.pgp
Description: PGP signature


Reply to: