Re: packaging the add-on libs...

[Greg Troxel <gdt@ir.bbn.com>]

  Even though this library issue seems to me like a potentially serious
  impediment to being able to upgrade from one version of guile to
  another gracefully, especially if guile has a lot of add-on libs
  provided by third parties, after talking to Bill, it seems that
  although going with libguile12-foo-bar would be likely fix the problem
  for guile, it still wouldn't address the same problem for all the
  other non-guile libs on the system.  i.e. what about opengl, libc, X
  etc.

  So I'm wondering if perhaps I'm just coming to fully apprehend what is
  in fact a common unix problem (when inter-library dependencies are
  involved), one that people just don't think about very often, and one
  that perhaps it's not guile's job to fix.

  Not sure.  What do others think?

I think all grief due to linking with guile really is guile's problem
to solve.  The other packages have to support either multiple versions
or be nearly 100% compile-time compatible with correct older source.

With libc, for example, there is a notion that programs compile
against the latest headers/libs, and that this latest version is
compile-time compatible with programs written for previous versions.
Then, one keeps old e.g. libc.so.3 around.  For libc, X11 and things
like that (at least on BSD - I haven't used Linux in a while) this
really is the case and things work fine.

With guile, the problem is that a program written for guile 1.4 will
not necessarily compile against guile 1.6, due to removal of
deprecated stuff and interface changes.  While it might be nice to
avoid this, guile isn't as mature as libc.  This lack of compatibility
causes guile to have the obligation to support simultaneous
installation of 1.4 and 1.6, at least until all the packages that want
1.4 have --without-guile added to their control files :-) Seriously -
that's what I suspect would happen.  I think we should strive for a
situation where package maintainers can easily have them both, and
then programs can get upgraded to use 1.6 'soon', rather than having a
huge flag day.

I'm less worried about guile-gtk, since that tends to get dynamically
loaded from a scheme script.  It's things like gnumeric, which on
FreeBSD links with 47 libraries, but not guile.  Gnumeric source
supports guile, but the pkg maintainer turned it off for some reason.
This is what I'd like to avoid - IMHO guile should strive to make it
easy for others to not only write code to use it, but to package with
it.

I suggest glib 1.2 and glib 2.0 as an example that is similar to guile
- a library used by lots of things, where 1.2 is still in wide use due
to programs that haven't been updated yet.  Of course, glib has more
mindshare than guile, but I think this is where we want to go.  We
might even use pkgconfig, which has support for finding versions at
least/most various values, and would avoid the guile-config name
collision.

Really, I'm arguing for putting the guile version number in the names
($(prefix)/include/guile16 and all).  Programs using guile-config and
later pkg-config hopefully should not be put out by this.

Sorry for rambling on again...

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel