Re: Release now?

[Greg Troxel]

   What do you think about my other suggestion?  i.e.

     - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir})
     - put the libguile.so development symlinks (i.e. the ones -l uses)
       in /usr/lib/guile/VERSION
     - put the headers in /usr/include/guile/VERSION
     - require the use of guile-config and arrange for guile-config to
       spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION
       when appropriate

I suppose /usr/share/guile/VERSION already exists, and /usr/bin/guile
(and guile-config) can be named with versions as well.

It strikes me as inelegant to link against a library in one place and
then expect ld.so to find it someplace else.
I think your plan is workable, but in my view the 'put the other
version in a different prefix' plan feels cleaner.  But, it requires
rpath or DT_RPATH, which seems to be ok in most places except debian.
(It is certainly heavily used in NetBSD, which puts third party stuff
in /usr/pkg and does not have /usr/pkg/lib in the default search path.)

At this point, for NetBSD I'm happy with NetBSD's current solution.  I
would be perfectly content for your plan to be a ./configure-time
option, as it seems to be among the best suggestions to date for a
no-rpath environment.  I suppose if guile-config/pkg-config spits out
the right -I and -L paths then this would be ok for other systems.
But having a library compile-linked from one place and run-linked from
another seems to be asking for trouble, and I would prefer not to see
that complexity and associated unintended consequences imposed on
everyone because Debian chooses not to use -rpath.  (I realize libtool
does this for running uninstalled code, but I think that's different.)

All that said, I have to ask myself: what's wrong with putting
the guile version number in the soname and all other files,
glib-style?  This makes names bigger, but seems less likely to create
hard-to-find bugs.  This could also be a ./configure-time option,
perhaps used only when installing a secondary version.  Or, on systems
that say dependency libs have to be updateable without reinstalling
dependent programs, this should perhaps be used all the time.

In December you wrote to debian-devel:

  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.

I think it is important to keep separate notions of scalability
imposed by such a naming scheme and the scalability of the underlying
reality.  Here, the reality is messy, and the naming scheme means that
various combinations can coexist peacefully.  It enables having 12
versions at once, but that is the underlying reality, unless some are
prohibited.  Of course, not having a mechanism has the effect of
prohibiting this.

  Why wouldn't such a rationale also justify
  libguile1.6-gwrap-glib1.2-crypt1-c6,so?

It justifies only libguile1.6-gwrap-glib1.2.  The key point that I've
been trying to get across (which our discussion has clarified in my
mind) is that there are two separate kinds of version changes.  One is
the traditional shlib major version bump.  But generally, that merely
means programs must recompile, and make an occasional small change.
The other kind is that interfaces have changed so significantly that
it isn't reasonable to tell people "Just recompile and fix your
program.  From now on only the new version is available and if you
can't cope you are just going to lose."

The "just cope" is what happens when libc has a major version change.
The work to cope is not too bad, and it isn't viewed as reasonable to
provide a way around it.  I'm hoping that guile 1.6->1.8 will be like
this.

Other changes, like glib 1.2 to 2.0, are so far reaching that the
maintainers feel the need to support having them both installed.  Part
of the reality is that the more important a library is, the more
effort the library can impose on users with changes.  With guile, we
want people to use guile more than they feel the need, so the amount
of pain we can impose is small.

        Greg Troxel <address@hidden>