Re: packaging the add-on libs...

From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: packaging the add-on libs...
Date: Thu, 10 Oct 2002 10:37:20 -0500	[thread overview]
Message-ID: <87hefucnkf.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <rmiptuisbhv.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "10 Oct 2002 08:51:24 -0400")

Greg Troxel <gdt@ir.bbn.com> writes:

> Putting the guile version in the name makes sense to me, and I'd go
> so far as to think about making libguile.a be libguile16.a.

(we'd probably want to use libguile12, not 16, unless you're talking
 about some future version, or unless we're planning to change guile's
 actual version number to track libguile's)

I've been wondering about this myself -- you'd also have libguile12.so
which would make it much easier to install multiple libguileX-dev
packages, but we'd still have to do something about the headers.
Perhaps /usr/include/guile/1.6.

>  Given how many things link to guile 1.4 (e.g. gnomeish stuff), it
> seems critical to make it easy for package systems to install both
> guile14 and guile16, and that therefore these must have totally
> disjoint sets of files, with the possible exception of the
> guile-config link to guile16-config.  A nice guile.m4 to find the
> 'right' version might also be an exception.

I'm planning to allow something like this on debian systems, though as
mentioned I haven't decided on all the details yet, with whether or
not we can/should allow multiple development version packages to be
installed at the same time being an open question.

> It's kludgy for packagers to add this, and causes extra differences,
> where if guile itself does it, it is just the way the world is and
> will be the same everywhere.

I'm inclined to agree here.

> On the other hand, putting all the dependent libs in
> $(prefix)/libexec/guile/1.6/ also seems quite sensible to me, as long
> as they are dlopened with an absolute path and no one is asked to put
> this in LD_LIBRARY_PATH :-) Following the path of the P crowd seems
> somewhat sensible, especially if there hasn't been large amounts of
> pain from that approach.

This still won't work if people are supposed to be allowed to link
directly against these libs, and they are (at least not without
-rpath, etc.)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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