Policies about shared libs (directly affects .deb packaging)

[Rob Browning]

While packaging Guile 1.6, I've tried to keep things as simple as
possible.  In accordance with that, and contrary to my previous
discussions with people, I've been trying to see if we could get away
without having to have a bunch of packages -- including one for each
shared library in guile.

My current Debian packaging arrangement includes four packages:

  Package: guile-1.6
  Package: guile-1.6-libs
  Package: guile-1.6-dev
  Package: guile-1.6-doc

The biggest questions surround guile-1.6-libs and guile-1.6-dev.  With
this arrangement, *all* the shared libs are in guile-1.6-libs, and
guile-1.6-dev contains all the .a files and .so links (and the .la
files for any libs that don't have their major soname in the library
name i.e. libguile and libqthreads for example -- this is OK because
these aren't candidates for dynamic-link).

The problem is that it's OK to put all the libs in one package if *and
only if* we agree to some fairly stringent restrictions upstream.  If
I'm thinking straight, the restrictions are:

  1) We may never change the major number of any lib during a stable
     release cycle.

     Rationale: as an example, if we bumped libguile-srfi-srfi-4-v-1
     to libguile-srfi-srfi-4-v-2 during the 1.6 series, and if there
     are applications that have been compiled against v-1, then when I
     release the new guile-1.6-libs package with v-2, all of those
     applications will be missing libraries.  That's not allowed.

  2) We must change the major number of *all* libs with every new
     guile release, i.e. when we go from 1.6 to 1.8.

     Rationale: imagine we didn't.  Imagine we only changed libguile
     from libguile.so.12 to libguile.so.13 when we went from guile 1.6
     to guile 1.8 but left all the other lib versions alone.  Then the
     guile-1.8-libs package would contain libraries with file names
     that collided with file names from the guile-1.6-libs package
     (which would need to stay around to support apps that still
     required guile 1.6).  Even if I made guile-1.8-libs
     conflict/replace guile-1.6-libs in this case, then you'd could
     have older apps that were still linked against libguile 12, but
     were also using the newer libguile-srfi-srfi-4 from guile-1.8
     that's linked against libguile 13.

Note that these two restrictions *are* fairly Draconian, and so we may
not want to accept them.  In that case, guile will have to be packaged
for debian with one package per shared lib.  However, bear in mind
that this is not a panacea.  We will still have upstream restrictions,
they'll just be less obvious.

No matter what we do, any time we change any .scm file, we have to
make sure that it doesn't directly or indirectly alter the API of
*any* lib inside guile in a way that requires that lib to change its
major number.  This includes alterations to any data structures
returned or modified by any function in the API.  The same goes for
any change to a .c file in libguile.  If that change alters anything
visible to the outside world via one of our libraries, then each
affected library's major number has to be changed.

Of course our development behaviors coupled these two restrictions
could have the practical effect of making us comply with requirements
(1) and (2) anyway.

If we don't want to promise to accommodate restrictions (1) and (2),
then guile will have to be comprised of at least:

  Package: guile-1.6
  Package: libguile-12
  Package: libqthreads-12
  Package: libguile-ltdl-1
  Package: libguilereadline-v-12
  Package: libguile-srfi-srfi-4-v-1
  Package: libguile-srfi-srfi-13-14-v-1
  Package: guile-1.6-dev
  Package: guile-1.6-doc

During packaging I will have to be careful to split up the .scm files
appropriately among the various lib packages, and we'll have to be
very careful here upstream not to create inter-dependencies among the
non-libguile .scm files that could cause problems across releases of
different versions of a given lib.

Thoughts?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu