library versioning: making upstream policy, need debian evaluation.
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.
Overall, we're trying to hammer out some details of how external
add-on libraries are going to be handled in the future guile, and
there are some tough issues, mostly related to upgradability over time
esp wrt to distributions. I apologize in advance for the message
length, but if you can bear with me, I'd *really* appreciate any help
with respect to the problem. I'm asking here both because
distribution maintainers have some uniquely specific information about
how things go wrong over time wrt versioning :>, and because the
upstream decision will affect all of debian's guile related packages,
and I'd rather make things easier on us rather than harder, other
things being equal.
Background: Guile is a little unusual as compared to the other
interpreters (and other packages in general) in that it expects at
least some of the shared libraries that provide guile functions to be
used both directly from C and from scheme (the language guile
implements). So libguile, for example, provides both the Scheme level
function "make-vector", so in scheme you can say (make-vector 4), and
exports the C level function "SCM scm_make_vector (SCM size), so you
can say "SCM newvector = scm_make_vector (SCM_MAKINUM (4)).
It is also possible (and ATM encouraged) to create "add-on" libraries
for guile that link against libguile and add to the set of available
scheme and C functions. Note that the SCM data type above is the type
guile uses to represent all its "objects". It is much like whatever
pointer perl uses to pass around lists/vectors/hashes/bigints, and
much like glib's GObject*. SCM is the basic guile "data type". Since
scheme (and guile) are very dynamic languages, and since all the API's
pass around the SCM type nearly exclusively, and since an instance of
an SCM may be an int, a list, a vector, a goops object, or who knows
what, then with each non-micro-version release, libguile guile pretty
much has to change sonames, and then transitively, so do *all* libs
linked against libguile (since the format or contents of some SCM
instance they might pass in/out of their API might now be completely
changed).
The problem: (In the example below, I'm being a little sloppy. There
isn't actually a guile-1.4 package, and it doesn't contain
libguile.so.9 (libguile.so.9 is actually in libguile9 ATM), but I'm
being sloppy to hopefully make the actual issue clearer. Please bear
with me.)
Say we have guile 1.4 upstream, and we have g-wrap, and say g-wrap (a
guile add-on) builds a "glib helper library" that allows you to
convert back and forth between glib GList*s and scheme lists. Presume
that gwrap names that library libgwrap-glib. So as actual products we
might have:
guile-1.4: (provides libguile.so.9)
libgwrap-glib1: (provides libgwrap-glib.so.1) (depends libguile.so.9)
gnucash: (depends libgwrap-glib.so.1)
some-other-app: (depends libgwrap-glib.so.1)
now lets say guile 1.6 is released and the guile maintainer gets ready
and produces
guile-1.6: (provides libguile.so.12)
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.
Doesn't debian forbid this this? If so, if a "1" is not acceptable,
then what would be, who chooses it, and when -- "make dist time",
"build time"?
I'm not positive, but I suspect this problem is why the gtk/gnome
packages have done something guile has been trying to avoid -- putting
the version name into the library name, i.e. you now have
libgtk-1.2.so.0 in package libgtk1.2, not libgtk.so.0 in package
libgtk or even in package libgtk-1.2. I also believe, but I'm not
positive, that other languages like perl, python, and ruby, probably
aren't quite as sensitive to this issue, because AFAIK unlike guile
they don't expect people to be using their language API from C so
directly (i.e. via -llibguile-foo), all the way down to the individual
"push/pop/append/map" level.
One solution might be to just require all guile add-on libs to be
placed in /usr/lib/guile/X.Y and then require the use of -rpath or
similar, but I suspect that's a non-starter. Another might be to make
it guile policy to encode the name of the guile version into the lib
name, i.e. libguile1.6-gwrap-glib, but that's pretty ugly and it's not
very scalable. Why wouldn't such a rationale also justify
libguile1.6-gwrap-glib1.2-crypt1-c6,so?
To some extent, from reading some of the old -rpath discussion with
Alexandre, it sounds a bit like we may be bumping up against the
long-standing problem that for a soname to really mean binary
compatibility, it would actually need to be a signature containing all
the sonames of all the sublibs if the library actually exports *any*
data types from any of its sublibs, or passes them among the APIs of
the libs that it depends on. i.e. our current C versioning strategies
don't allow you to be all that accurate.
i.e. according to the normal unix versioning model, where supposedly
soname == binary compatibility, in the example above, libgwrap-glib
should change its soname whenever the soname of the libguile that it's
linked against changes -- at *build* time, but of course that would
create all kinds of chaos without more info, a different model, and a
smarter linker.
So what to do?
(For those more deeply interested, there has been discussion of this
off and on on guile-devel@gnu.org for a while.)
And if you made it this far, thanks very much ;>
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Reply to: