Re: Release now?

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

  To me, it seems like the -L/usr/lib/guile/VERSION solution would allow
  the same result, but without the library naming issues.  You'd have:

    /usr/lib/libguile.so.9*
    /usr/lib/libguile.so.12*
    /usr/lib/libguile.so.14*

    /usr/lib/guile/1.4/libguile.so -> /usr/lib/libguile.so.9.0.1
    /usr/lib/guile/1.6/libguile.so -> /usr/lib/libguile.so.12.0.4
    /usr/lib/guile/1.8/libguile.so -> /usr/lib/libguile.so.14.0.2

  Just to be sure I understand, is your objection to this primarily a
  concern with it being an untested approach?  I just want to make sure
  we're on the same page.

No, we're not.  My objection, deep down, is a philosophical discomfort
with linking against a library in one place and expecting the run-time
linker to find it someplace else.  This just seems to be Wrong and
tempting fate.  Maybe I just need to get over this - it is probably a
remnant from early exposure to systems that stored the whole path, or
SunOS where -R was the default automatically from -L.

I think I also have an objection to doing things to accomodate people
who refuse to use -rpath, since to me the resulting pseudo-requirement
to put all libraries in /usr/lib (or use LD_LIBRARY_PATH) is totally
unreasonable.

Your proposal does seem likely to impose fairly little pain and save a
lot.  I would like to make sure that one can have different pkg-config
files and select the right one, since IMHO pkg-config will replace
guile-config eventually.

There is a large transition question, though - guile 1.6 already has
libraries in a particular place.  For 1.8 to have a new place is
probably fine, but this would be disruptive to those who have already
found a satisfactory solution.  Hence my notion of having the
version-named midfix be optional, so Debian can use it and NetBSD can
keep using separate prefixes.

Also, we might consider having a different prefix rather than a
'midfix', which seems awkward.  With /usr/lib/guile/1.4, guile/1.4
gets appended to $(libdir).  The alternative of /usr/guile/1.4/lib,
where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me.

This latter scheme is in fact what NetBSD does, except that -rpath is
used to find the libguile.so at run time from /usr/pkg/guile/1.4/lib,
and it isn't present in /usr/lib/libguile.so.

So, setting the prefix, and some optional glue code to symlink in the
libs (and guile-config with versions) to the 'real' $(prefix)/lib
would probably buy us the best of both worlds.  And, there would be a
harmonized solution between NetBSD and Debian, modulo the 'use -R
v.s. make symlinks in /usr/lib' difference.  To me, that bodes well
for it working elsewhere.

(With 20/20 hindsight, guile really should have got this right long
ago, but I didn't contribute code/solution then, so I have no
absolutely no right to complain.)

Summarizing:

  If the installed locations of guile 1.6 changes, I object because it
  will cause work for people who have already coped.

  I prefer the different prefix rather than a midfix.  A configure
  option to add a midfix seems ok, but given that we already have
  --prefix, it seems like more work.

  If the default behavior includes either midfixes or extra symlinks,
  I object, because it is imposing what some may view as uncleanliness
  on everyone because some decline to use -R.

  Differing prefixes and a ./configure option to symlink into another
  prefix is a clean solution which can be used in varying
  environments, enabling each to win while preserving their sense of
  the right way to do things.

        Greg Troxel <gdt@ir.bbn.com>


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