guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

packaging the add-on libs...


From: Rob Browning
Subject: packaging the add-on libs...
Date: Thu, 10 Oct 2002 00:03:42 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]