Re: Release now?

[Rob Browning]

Greg Troxel <address@hidden> writes:

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

I'm somewhat tempted to try it in HEAD, and then get as many people as
possible to attempt a build/install.  If it works on a bunch of
platforms, and if we can't think of any reason why it shouldn't work
in general, this might be a way to have one approach that works
everywhere.

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

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.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4