Re: Better support for transition to guile-1.6

[Rob Browning]

Marius Vollmer <address@hidden> writes:

>> So people would need to name their libraries say libfoo4.so... and
>> then you'd say (dynamic-link "libfoo4")?
>
> Even better!  I was thinking about putting them into specific
> locations like $(libdir)/foo/4/libfoo.la and then using
>
>     (dynamic-link (string-append libdir "foo/4/libfoo"))
>
> But just using $libdir/libfoo4.la is much simpler!

It also helps identify/avoid name clashes with existing libs -- if we
used the subdir approach, then one day, when we can specify the
interface number, we might have clashes to deal with when we moved the
libs into the main lib dir.

>> If so, would libfoo4 be provided via a symlink, or what?  We'll still
>> need the plain old libfoo.so.4... around, otherwise direct C linking
>> won't work right,
>
> Yes, that would be the compromise until dynamic-link understands
> versions.  I don't think symlinks will work right since it might trick
> the dynamic linker to load a library twice, under its two names.

But we'd have the same problem if we provided the lib twice under two
names, wouldn't we?  It seemed to me that a symlink was more likely to
prevent duplicate loads.  If ldso is smart, it should probably be
using the resolved inode number anyhow.

> Yes.  How long do you think will we have to wait for versions in
> dynamic-link?

Well, I have no idea whether or not the libtool people will even like
the idea, and even if they do, I don't know what their development
cycle is like since I just joined the list.  Anyone else have any
experience?

The recent bugs I've found in ltdl.c have made be a little wary of the
code, though.

As an interim measure, do you think we could go ahead and adopt the
interface we eventually want, say (dynamic-link "libfoo" 4), and then
implement some logic ourselves in dynl.c?  That and a little bit of
documentation telling people how they have to set up their symlinks
(or whatever) might allow us to let people start writing code that
they won't have to change later.  I can provide an implementation of
the libtool versioning logic -- I believe we already have one in
gnucash in the gnc-module code.  If not, it should be easy to
translate.

(I'm talking about the algorithm that given a required interface
 number X, tells you if library version A.B.C will satisfy that
 requirement.)

> Is that a big problem or can it be mostly automated?  (Is this where
> Debian has its impressive package statistics from? ;-)

I have to add the infrastructure to the debian/* build scripts by
hand, but after that it'll mostly be automated.  The Debian 1.6
packages are going to have some fairly major changes anyway.  I
inherited guile just during the transition to 1.4, so I wasn't fully
up to speed.  Now I know what needs fixing.  Also, I may try to
re-package from scratch based on the old packaging so that the code
can be added to guile CVS if we decide that's useful.

>From the user's perspective, having those extra packages is no big
deal (other than just adding to the noise in dselect's package
display).  When they install the main guile-1.6 package, all those
other packages will be sucked in automatically.

> Just for understanding, why do we need these different packages?
> Isn't it enough to put all libraries into one package?

Imagine I had packaged guile 1.3.4 with just a package containing
libguile.so.6 named libguile rather than libguile6.  People would have
built build other Debian packages that depended on libguile.so.6, and
so their packages would have listed a dependency on libguile (packages
like gnome-guile, guppi, etc.).  Now when guile 1.4 comes out, if I
just produce a new libguile package containing libguile.so.9, what
happens?  If a user were allowed to install that package, all the
other packages compiled against libguile.so.6 would break.  So we'd
have to set up the dependencies so that the user couldn't install that
package until every other package on the system that depended on
libguile had been updated.  That's what Red Hat does, and it's an
organizational nightmare, not to mention a huge stall in the
development process.

If you just make sure to have a separate binary package for each
versioned lib on the system whose name includes the major soname, then
you have no problems.  libguile6 and libguile9 can be installed at the
same time, and other packages can depend on whichever one they need.
This means that the upgrade can be much more incremental, and older
versions of guile can live on the system for as long as they are
needed.

The only thing you can't do is have more than one development package
installed at a time, but that's generally not a big problem,
especially if switching between them is as easy as:

  apt-get install guile-1.3-dev
  apt-get install guile-1.4-dev

etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD