Re: Better support for transition to guile-1.6

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> > I think we should work with the libtool guys to add this feature to
> > libltdl or libtool as a whole.  Off hand, I think the libtool would
> > need to be changed so that multiple versions of a ".la" file can be
> > installed simultaneously.
> 
> Already done yesterday :>

Ahh, need to read the libtool mails...

> > Before we have that feature, we can make sure that passing an absolute
> > file name to `load-extension' without an extension will work.  We can
> > then tell people that need to distinguish between multiple versions of
> > a plugin that they can install each version into their own directory,
> > and pass the absolute filename (without ".so" suffix etc) to
> > `load-extension'.
> 
> 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!

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

> OK, so here's a first stab at a policy:
> 
>   1) All of our libraries will be versioned, even "semi-internal"
>      ones.
> 
>   2) For the first release of a given library that needs to be
>      dynamic-linked (i.e. our current releases), we'll just name them
>      libfoo.X.so and you can access them from guile via (dynamic-link
>      "libfoo").
> 
>   3) For subsequent releases where the interface has changed in a
>      backward compatible way, until we have a dynamic-link that
>      supports an interface argument, the "interface number" must be
>      added to the name of the shared library, so we would have
>      libfooX.Y.so and would say from scheme (dynamic-link "libfooX").
>      (I'm not sure whether or not X and Y would always be the same --
>      I'd have to re-examine the libtool versioning algorithm).
> 
>   4) Eventually we hope that dynamic-link will support an "interface
>      number" argument and so we can drop the number in the library
>      name and have instead (dynamic-link "libfoo" 4) or similar.
> 
> Does that seem right?

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

> For debian, this means that guile's about to split into a much larger
> number of packages, I'll at least have to add:
> 
>   libguilereadlineX
>   libqthreadsY
>   libguilesrfi-srfi-4-0
>   libguilesrfi-srfi-13-14-0
> 
> so that we can support guile version transitions smoothly.

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

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