Re: packaging the add-on libs...

[Rob Browning <rlb@defaultvalue.org>]

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