packaging the add-on libs...

packaging the add-on libs...

[Rob Browning]

I spoke with Marius a little while back about some of the complexities
involved in properly managing the versioning of our add-on libs, both
those we provide, and those provided by others, and working on
packaging guile 1.6 makes some of these issues clearer and more
immediate.

Consider libguile-srfi-srfi-4-v-1 which will be linked against a
particular libguile.  What guarantees are we going to make about
future releases of this add-on lib?  Do we guarantee that we'll always
change its major number whenever we release a new libguile?  It seems
like we must, since otherwise we could have outside apps or libs
linked against a set of add-on libs that point to a mixed set of
libguile versions.

As an example, say libguile13 ships with libguile-foo-v-1 and
libguile-bar-v-7, and libguile14 ships with libguile-foo-v-2 and
libguile-bar-v-7.  At this point we have a problem.  Any older app on
the system that was originally linked against libguile13,
libguile-foo-v-1, and libguile-bar-v-7 would still have all its
package depdendencies satisfied and would link at runtime without any
problems (at least I think it would), but it would be using libguile13
via foo and libguile14 via bar.

Presuming my analysis is right, I guess maybe we can just try to make
sure the rules about versioning your add-on libraries are clear, but
I'm concerned that a lot of people (especially people writing add-on
libs outside the core -- if we end up with a lot of them) may not
always remember or know the rules, and it seems like the resulting
bugs could be subtle and hard to track down.

One clear solution might be to just establish the convention that you
always embed the libguile major version number in the add-on lib's
name.  This seems like it would eliminate the possibility for error on
this front, but is a little unusual. i.e. instead of
libguile-srfi-srfi-4-v-1, etc., you'd have:

  libguile12-srfi-srfi-4-v-1
  libguile12-srfi-srfi-13-14-v-3
  libguile12-foo-bar-v-4

etc. 

Thoughts?

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

Re: packaging the add-on libs...

[tomas]

On Thu, Oct 10, 2002 at 12:03:42AM -0500, Rob Browning wrote:
> 
> I spoke with Marius a little while back about some of the complexities
> involved in properly managing the versioning of our add-on libs [...]

[snip]

> As an example, say libguile13 ships with libguile-foo-v-1 and
> libguile-bar-v-7, and libguile14 ships with libguile-foo-v-2 and
> libguile-bar-v-7.

[snip]

> [the system] would be using libguile13 > via foo and libguile14
> via bar.
> 
> One clear solution might be to just establish the convention that you
> always embed the libguile major version number in the add-on lib's
> name.

[snip]

>   libguile12-srfi-srfi-4-v-1
>   libguile12-srfi-srfi-13-14-v-3
>   libguile12-foo-bar-v-4

Looks viable to me (but not excitingly beautiful, mind you ;)

At the risk of boring you all (or even of being flamed out of the
list ;-) I'd like to repeat what has been (or is being) discussed
in another thread. The Big Guys (those with the P in the name, you
remember) have version-dependent [1] subdirectories where they
stuff the modules into which `belong' to the interpreter [2]. This
is a strategy also followed by Emacs. I think this approach might
minimize the problems you expose above.

Of course, Marius is right in not wanting to introduce gratuitous
dependencies and trying to distribute modules which are usable as
either guile extensions or as shared libs on their own. But those
shouldn't care about which guile version they are linked against
(or even whether there is guile around at all), and I'd expect them
to provide some (even if stripped down) functionality in any case.

---------
[1] Dependent on the version of the main interpreter, that is.

[2] I see two criteria to decide whether a module `belongs' to
    the interpreter: (a) it cares enough about the version of the
    interpreter it gets (dependencies on the API or ABI), and
    (b) it doesn't make much sense (or wouldn't even work) without
    *some* version of the interpreter (e.g. a debugger or profiler
    for guile). Note that (a) is stronger -- still I'd plea to
    stuff modules satisfiyng (b) into a guile-specific (maybe
    not version-specific) directory.
    Note that your example above libguile-foo-v-1 satifies (a).

Hope I've been clear

Thanks
-- tomas


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

Re: packaging the add-on libs...

[Greg Troxel]

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

IIRC {Free,Net}BSD took this approach when packaging glib, so that
glib10 and glib12 could coexist.  Now, glib-2.0 (which is to glib 1.2
as guile 1.6 is to 1.4, more or less, I think) has a different name:
> l /usr/pkg/lib/libglib*
-rw-r--r--  1 root  wheel  497840 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.a
-rwxr-xr-x  1 root  wheel     774 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.la
lrwxr-xr-x  1 root  wheel      18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so -> libglib-2.0.so.0.1
lrwxr-xr-x  1 root  wheel      18 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0 -> libglib-2.0.so.0.1
-rwxr-xr-x  1 root  wheel  430869 Jun 20 15:27 /usr/pkg/lib/libglib-2.0.so.0.1
-rw-r--r--  1 root  wheel  183560 Nov 21  2001 /usr/pkg/lib/libglib.a
-rwxr-xr-x  1 root  wheel     733 Nov 21  2001 /usr/pkg/lib/libglib.la
lrwxr-xr-x  1 root  wheel      16 Nov 21  2001 /usr/pkg/lib/libglib.so -> libglib.so.13.10
lrwxr-xr-x  1 root  wheel      16 Nov 21  2001 /usr/pkg/lib/libglib.so.13 -> libglib.so.13.10
-rwxr-xr-x  1 root  wheel  151468 Nov 21  2001 /usr/pkg/lib/libglib.so.13.10

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.

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.

But this still leaves the issue of libguile.a, which currently would
collide on my NetBSD system if I had 1.4 and 1.6 in the same prefix.
It is necessary to have both installed for compiling with, not just
running, since people need to be able to build programs from source
that link against older guile versions.

        Greg Troxel <gdt@ir.bbn.com>


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

Re: packaging the add-on libs...

[Rob Browning]

tomas@fabula.de writes:

> At the risk of boring you all (or even of being flamed out of the
> list ;-) I'd like to repeat what has been (or is being) discussed
> in another thread. The Big Guys (those with the P in the name, you
> remember) have version-dependent [1] subdirectories where they
> stuff the modules into which `belong' to the interpreter [2]. This
> is a strategy also followed by Emacs. I think this approach might
> minimize the problems you expose above.

It's been stated that we're going to keep all the directly linkable
libs in the "normal place".  That means /usr/lib, and that would apply
to all the add-on libs so far (i.e. we don't have any non-directly C
linkable) add-on libs right now.

I guess you could argue for a versioned directory for any new shared
libs that aren't supposed to be directly linkable by any other apps or
libs.

> Of course, Marius is right in not wanting to introduce gratuitous
> dependencies and trying to distribute modules which are usable as
> either guile extensions or as shared libs on their own. But those
> shouldn't care about which guile version they are linked against (or
> even whether there is guile around at all), and I'd expect them to
> provide some (even if stripped down) functionality in any case.

These libraries *have* to care about which guile version they're
linked against.  For example, libguile-srfi-srfi-4-v-1 *has* to be
linked against libguile12 so it can use even primitive operations like
car and cdr.  And of course libguile12 depends intimately on the
particular source in ice-9/ that it comes with.  There's no such thing
as a stand-alone guile module/shared-lib.  If they don't depdend on
libguileX, they can't *do* anything -- no car, no cdr, no GC, 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

Re: packaging the add-on libs...

[Rob Browning]

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

Re: packaging the add-on libs...

[tomas]

On Thu, Oct 10, 2002 at 10:22:42AM -0500, Rob Browning wrote:
> tomas@fabula.de writes:
> 

[...]

> It's been stated that we're going to keep all the directly linkable
> libs in the "normal place".

Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
then and still feel uneasy abut it (see below).

>                              That means /usr/lib, and that would apply
> to all the add-on libs so far (i.e. we don't have any non-directly C
> linkable) add-on libs right now.
> 
> I guess you could argue for a versioned directory for any new shared
> libs that aren't supposed to be directly linkable by any other apps or
> libs.

Yes, kind of. Only that I'd substitute ``that aren't supposed to be
directly linkable by'' for ``that have to go with guile to be linked
by...''

In other words, if you need guile in conjunction with libfoo, then
libfoo has no business in /usr/lib or /usr/local/lib -- but rather
in /usr/lib/guile/1.6/ (or something like that). IMHO, of course.

[snip]

> These libraries *have* to care about which guile version they're
> linked against.  For example, libguile-srfi-srfi-4-v-1 *has* to be
> linked against libguile12 so it can use even primitive operations like
> car and cdr.  And of course libguile12 depends intimately on the
> particular source in ice-9/ that it comes with.  There's no such thing
> as a stand-alone guile module/shared-lib.  If they don't depdend on
> libguileX, they can't *do* anything -- no car, no cdr, no GC, etc.

Well -- one could imagine (say) some regexp library or some DBM library
which is delivered with guile but would make sense as a stand-alone.
If it's possible to keep the glue code separate, it might be possible
to make it guile-independent (my hazy memory suggests SDBM from Perl
as an example, but may be I'm forgetting important bits here).

Regards
-- tomas


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

Re: packaging the add-on libs...

[Rob Browning]

tomas@fabula.de writes:

> Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
> then and still feel uneasy abut it (see below).

Well FWIW, I did some experimentation, and at least on debian systems,
during the process of re-building/uploading which would happen every
time we release a new major version of libguile, I determined that you
are likely to end up with cross-version-links.

In my example (imagine libbase is libguile):

  $ ldd .libs/some-app-2
	libuses-base-foo2.so.2 => not found
	libbase2.so.2 => not found
	libuses-base-bar.so.1 => not found
	libbase1.so.1 => not found
	libc.so.6 => /lib/libc.so.6 (0x40027000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Note that in the expirimental tree, some-app-2 was only linked via
libtool against libuses-base-bar and libuses-base-foo2, the two
libbase links were pulled in because uses-base-foo2 and uses-base-bar
were originally linked against two different versions of libbase.

I don't know if how this would work on other platforms, but what's
interesting is that at runtime, it appears that the loader resolves
any duplicate symbols in favor of the first library listed on the
libtool link line.  In this case, even though libuses-base-foo2 was
linked against libbase2, when it calls libbase_init, it prints the
message I put in libbase1's libbase_init.  There are no linkage
warnings.  libuses-base-bar was listed first on the libtool link line,
and if I reverse that so that libuses-base-foo2 comes first, then we
see the messages from libbase2.

In some sense, this could be seen as a good thing, and would hide most
problems, i.e. even though you have dual linkage, you always get the
symbols from just one version of the libs, but in reality I believe
it's a potential disaster since (for example) libuses-base-foo2 was
built using libbase2's headers, and libuses-base-bar was built using
libbase1's headers.  This means that one of them is going to be
operating on libbase data structures with the wrong set of macros.
Another potential problems comes if libbase2 adds new functions or
deletes old ones, then depending on whether libbase2 or libbase1 takes
precedence in the "dual link", you'll have some functions from one
version of libbase and some from another.

> Yes, kind of. Only that I'd substitute ``that aren't supposed to be
> directly linkable by'' for ``that have to go with guile to be linked
> by...''
>
> In other words, if you need guile in conjunction with libfoo, then
> libfoo has no business in /usr/lib or /usr/local/lib -- but rather
> in /usr/lib/guile/1.6/ (or something like that). IMHO, of course.

The main problem with this is that any apps or libs linked against
these "add-on" libs will have to do something special to access the
libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc.  and as we've
discussed, there are some definite issues with doing that portably,
and in a way that doesn't have the potential to interact badly with
other libs that might do the same thing, so we'd have to be cautious
when considering this approach.  For libs no-one's ever allowed to
link directly to, there's no problem.

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

Re: packaging the add-on libs...

[Rob Browning]

tomas@fabula.de writes:

>> It's been stated that we're going to keep all the directly linkable
>> libs in the "normal place".
>
> Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
> then and still feel uneasy abut it (see below).

Actually, one other thing I wanted to mention (and have already
mentioned to Marius).

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?

The problem is that if we don't do anything, there *will* likely be
trouble if we release guile-XY, with a new major version of libguile
and the system has some library or app blarg that depends on
libguile-someones-foo and libguile-someone-elses-bar.  If lib*foo gets
upgraded on the system before lib*bar does, then blarg will likely end
up being indirectly linked against 2 different major versions of
libguile until a new major version of lib*bar is released.

I was hoping we could avoid intermediate brokenness like that, but
perhaps we can't.  I guess in debian that would just mean another one
of those periods during a major interpreter migration where things are
very shaky.

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

Re: packaging the add-on libs...

[Greg Troxel]

  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

Re: packaging the add-on libs...

[Rob Browning]

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

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

It's not just the compilation issue.  To take your libc example, the
issue in question is what happens if app blarg uses both libfoo1 and
libbar1, and both of these are compiled against libc6, and then libc7
comes out.  Say shortly thereafter libfoo2 comes out, compiled against
libc7.  If blarg is now recompiled, it'll get libfoo2 and libbar1 and
hence will be indirectly linked against both libc6 and libc7
until/unless a new libfoo comes out that's linked against libc7.

Is the answer "well, then blarg will just have a potential problem
until libbar is updated"?

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

Being able to have both installed would keep us from stalling all the
developers during the transition period, but it won't really help with
the problem above.  I believe the libguileX-somelib naming convention
would fix the problem, but as mentioned, only for guile.  It wouldn't
address the broader unix inter-lib version problem, and so perhaps we
should just suffer along with everyone else through the (hopefully
brief) transition periods.

The transition period would consist of the time between when a new
libguileX comes out, and when all the "add-on libs" that depend on the
old version of libguile are rebuilt against the new version of guile.
Actually it's only the add-on libs that are actually used by some
other app or lib that also uses some other add-on lib that cause
trouble, but we can't predict that.

Of course, if it takes a long time for add-on libs that are commonly
used in conjunction with other guile libs to get updated, then the
"transition period" could be long.  For example, if there were a
libguile-gobject that languished, that could really hold things up.

> I'm less worried about guile-gtk, since that tends to get dynamically
> loaded from a scheme script.

Right.  Guile-gtk's not really a good example, but an external
libguile-gobject that you could call from other C libs/programs would
be a good example, say one that provided scm_gobject_create_obj () or
whatever.

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

glib's only a good example if you consider it in a broader context.
Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to
compile against glib 2.0 but libgnome-print has not.  Where does this
leave evolution when it recompiles (presuming it links against both
libs)?

(I'm not sure this particular case would be a problem, but it's an
 example of the broader issue...)

> Sorry for rambling on again...

Not at all.  I appreciate the effort.  This is too complicated for me
to even want to try to figure out on my own.

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

Re: packaging the add-on libs...

[Greg Troxel]

  It's not just the compilation issue.  To take your libc example, the
  issue in question is what happens if app blarg uses both libfoo1 and
  libbar1, and both of these are compiled against libc6, and then libc7
  comes out.  Say shortly thereafter libfoo2 comes out, compiled against
  libc7.  If blarg is now recompiled, it'll get libfoo2 and libbar1 and
  hence will be indirectly linked against both libc6 and libc7
  until/unless a new libfoo comes out that's linked against libc7.

  Is the answer "well, then blarg will just have a potential problem
  until libbar is updated"?

I don't think we can solve everything.  But here, if one rebuilds all
the packages from source, libbar1 will get linked against libc7 and
things will be ok.

  The transition period would consist of the time between when a new
  libguileX comes out, and when all the "add-on libs" that depend on the
  old version of libguile are rebuilt against the new version of guile.
  Actually it's only the add-on libs that are actually used by some
  other app or lib that also uses some other add-on lib that cause
  trouble, but we can't predict that.

A bit of pain while guile add-ons are revved is one thing, but I would
really like to avoid pain on guile-using apps, since they'll just
stop.  guile add-on writers are guile weenies who will not give up so
easily.

  glib's only a good example if you consider it in a broader context.
  Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to
  compile against glib 2.0 but libgnome-print has not.  Where does this
  leave evolution when it recompiles (presuming it links against both
  libs)?

This leaves evolution broken, I think.  I think the gnome folks may
create libgnome-vfs2, so that gnome2 apps can use that, and the older
apps can use libgnome-vfs.  As an example, orbit2 uses glib 2.0, so
when switching from glib 1.2 to glib 2.0, one switches to orbit2.
This would be easier if f.i. guile-gtk went under
$(prefix)/share/guile/1.6 rather than $(prefix)/share/guile directly.
But, I don't think such add-ons are super critical in terms of total
pain and worry about guile market share loss.

I agree that the problem is not completely solveable.  But, I think
the real question is

  What can guile do that minimizes pain to people who write
  applications using guile, and people that maintains
  pkgsrc/ports/deb/rpm of such programs and guile itself.

(For what it's worth, I have guile 1.6 installed in /usr/projectname
for a project I'm working on that uses a guile-gtk GUI to monitor
things.  This doesn't conflict with /usr/pkg/bin/guile, which is 1.4
for gnome etc., as long as I use the change to look up helper libs at
absolute pathnames.  But a different prefix isn't ok for NetBSD's
pkgsrc, and I bet it's not ok for Debian either.)

        Greg Troxel <gdt@ir.bbn.com>


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

Re: packaging the add-on libs...

[tomas]

On Fri, Oct 11, 2002 at 10:59:53AM -0500, Rob Browning wrote:
> tomas@fabula.de writes:
> 
> > Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
> > then and still feel uneasy abut it (see below).
> 
> Well FWIW, I did some experimentation [...]

[enlightening example snipped]

I totally agree with you in that this double linkage leads to undefined
behaviour (different from system to system and probably not explicitly
documented on most systems, so that e.g. ld-linux.so might feel free to
change its behaviour some day without saying so). It's most undesirable,
so I think the ideas you posted elsewhere (checking the lib version I'm
linked against to catch this case) are definitely worth a try.

[...]

> The main problem with this is that any apps or libs linked against
> these "add-on" libs will have to do something special to access the
> libs, i.e. -rpath, mangling LD_LIBRARY_PATH, etc.

That was more or less what I was pleading for: in the cases we can
(that is: for what can be considered a guile ``plugin''), do it --
in the cases we can't (that is: ``standard system libs''), well,
don't -- just use system standard searching and loading mechanism.
That imposes the burden of differentiating plugins from simple
libraries (in a way less elegant). But it buys us something.

>                                                    and as we've
> discussed, there are some definite issues with doing that portably,
> and in a way that doesn't have the potential to interact badly with
> other libs that might do the same thing, so we'd have to be cautious
> when considering this approach.  For libs no-one's ever allowed to
> link directly to, there's no problem.

You have more experience with those issues than me, so I'm ready to
shut up, having made enough noise already ;-)

Regards
-- tomas


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