Re: Policies about shared libs (directly affects .deb packaging)

[Rob Browning]

Neil Jerram <address@hidden> writes:

> The one problem scenario would be a lib in the core distro that wanted
> to change much faster than the rest.  In this case, could we unbundle
> just that one library?  In other words, if we try out these
> restrictions for a while and they don't work for some library, is
> there a recovery path?

I'd have to think carefully to be sure, but I *think* that might be
OK.  If we unbundle a lib, then the next micro revision of
guile-X.Y-libs would come out along with a libguile-foo-Z package.
This package would Depend on guile-X.Y-libs (>= new-revision), but
would also have to "Conflicts: guile-X.Y-libs" and "Replaces:
guile-X.Y-libs".  One drawback is that this could get messy in the
control file over time if we do it very often.

> Just to be sure, though, what are the changes that should cause us
> to increment the major number of a library?

libFOO's major number would need to be bumped given any changes that
could break any app or lib that used to be linked against the previous
copy of libFOO, and as I mentioned later, I think that in our case it
may sometimes be more than just the .c files since some lib's
corresponding .scm files could change their semantics in ways that
break backward compatibility wrt the *C* API, even if the C code
hadn't changed (see your and my comments below).  Note that this is
only true if the .c code is allowed to call functions or use variables
provided by the .scm files (or perhaps pass them out as data).  If we
wanted to make the restriction that that's not allowed, that .c code
may not depend on .scm files, then it should only be changes to the .c
files that can affect a lib's binary compatibility.  (Actually it's
the headers too since of course they can actually embed code in
*other* libs or apps).

The libtool info pages have a semi-decent explanation of why/when you
have to bump the major soname, though they call it the "interface
number", and as I recall they may not specifically address the fact
that even if the lib in question's code doesn't change, if that lib
re-exports data structures or functions from a sub-lib, then the lib
must to bump its soname whenever anything in the sub-lib changes "in a
relevant way" that the lib passes on via its API to its clients.

The above is my current understanding -- so everyone, please correct
me if I'm wrong.

>     Rob> No matter what we do, any time we change any .scm file, we have to
>     Rob> make sure that it doesn't directly or indirectly alter the API of
>     Rob> *any* lib inside guile in a way that requires that lib to change its
>     Rob> major number.
>
> What about scm_eval_string("(proc-whose-behaviour-just-changed)") ?

Good question, and one I think we need to answer, or even more
specifically imagine libguile-foo with:

   SCM scm_public_function_do_foo ()
   {
      return scm_eval_string ("(make-a-foo)");
   }

I've wondered about this for a while, and I think I talked to Marius
about it, but I can't recall what if anything was decided.

> This sounds a lot like hard work, and probably a worse nightmare than
> having your proposed restrictions.

It's not actually a ton of work since I've got a decent amount of it
automated, but it *is* more a more complicated arrangement for people
to understand when coming to guile.  It may, however, be the thing we
need to do...

And on a somewhat related note, I do worry a little that we may be
setting ourselves up for some unpleasant impressions from the broader
unix community with our library approach, though I don't have any good
solutions that aren't going to aggravate someone.

Our current approach makes sense, but imagine we do become a lot more
popular.  Is the broader non-scheme, non-guile community going to be
tolerant of the placement of hundreds of libguile-* libraries into
/usr/lib?  If we ever get to even a fraction of the number of add-on
packages in CPAN, that's where we'd be headed.  Not sure it matters,
and I'm not saying we should change our behavior, but I wanted to make
sure everyone's thought about some of the these potential "mostly
non-technical" issues.

It's my impression that perl and python, etc. don't suffer from this
nearly so much b/c they don't support/encourage the direct linking we
do.  Actually let me rephrase that -- they *do* suffer from the
"bazillion small packages problem", i.e. search debian for lib*-perl
packages, but they don't suffer from the "bazillion files in /usr/lib"
issue.

FWIW.

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