Re: add-on lib versioning (concrete example g-wrap) -- what to do?

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> But is it a genuine Guile problem?  What is the difference between
> libguile and, say, libX11?  Libguile is changing incompatibly much
> more often than libX11 is, and people don't want to have multiple
> incompatible versions of libX11 on their system simultaneously.

Actually I don't know enough about X11's API and protocols to address
that issue clearly, but as I recall, the X11R5 to R6 transition was a
big pain and wouldn't be something people would be likely to want to
revisit with each upstream release.  i.e. it's OK to do it once every
so many years, but not with each release.  The same applied for the
libc5 to libc6 release.  The problem is that it looks like we're
setting ourselves up to throw everything into upheaval with each
non-micro upstream release.

> So we should probably works towards that as well: we should give
> people no reason to want to compile new software against Guile 1.4.
> Why do they want this?

I believe people have kept libc5 stuff and old X11 stuff around for
long periods of time.  Even in Debian it takes a little while for
everything to get recompiled against the newer libs, and some things,
the ones that can't be recompiled b/c of source differences are
usually expected to continue to function -- they just have to compile
against the older libs, i.e. they Depend: libguile9 rather than
libguile12. My point isn't about whether or not people should be
encouraged to migrate to the new version, it's about whether or not we
should break a bunch of existing stuff on their system when they just
want to upgrade a few things.

The real issue isn't evident when considering just the "individual
compiling stuff on their own machine" perspective, but it is much
clearer when you think of the the problem from a distributor's
perspective.  From a distribution perspective libs have to pick
sonames that allow system upgrades without breaking old software.

Say we 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)
   snd: (depends libgwrap-glib.so.1)

now the guile maintainer gets ready and produces

   guile-1.6: (provides libguile.so.12)

and now the gwrap maintainer wants to rebuild his package against the
new guile.  So he rebuilds gwrap and we have:

   libgwrap-glib???: (provides libgwrap-glib.so.???) (depends libguile.so.12)

What goes where the ??? is above?  If a "1", then as soon as the gwrap
maintainer uploads the new gwrap packages and they're installed, both
gnucash and snd are broken, even though all of their dependencies are
still satisfied.  Debian doesn't allow this.  So if not "1", then
what, and who chooses it?

I'm not positive, but I suspect this problem is why the gtk/gnome
packages have done something we've been trying to avoid -- puting the
version name in 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.
   
One super-heavy-handed way you could avoid the problem is to just make
policy that two versions of guile can't coexist in a distribution at
the same time *period*, and require all guile based debian packages to
name themselves somehow based on the guile they're compiled against,
and then include package dependencies that would force all packages
using the old guile (directly or indirectly) the system when the new
guile is installed, but this is not likely to win us any friends, and
it's likely that not all the various maintainers would even remember
to set these dependencies right all the time.

All that said, let me be clear, I don't really like the solutions I'm
proposing, and I'd actually prefer if we could just use the "put libs
in /usr/lib, don't cruft up our lib names, and let ld.so sort it out"
approach.  That's a lot nicer looking, but so far it still looks to me
like that approach is unlikely to scale.

-- 
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