Re: [PATCH] Thread Plug-in Support #2

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> Luckily, Guile is flexible enough so that you can construct some
> versioning yourself, without explicit support.  For example, you can
> decide whether you want to use Gtk-1.2 or Gtk-1.3 (2.0 by now?) by
> loading either the module (gtk-1.2 gtk) or (gtk-1.3 gtk).  When you
> load just (gtk gtk) you get a default version.  When you load both,
> you get an error.

This might be good enough, but if we're going to follow this route,
then it seems like we probably need to make a policy that all guile
add-on packages should always use API version numbers in their names
and all packages that depend on those packages should use the
versioned names in their use-modules statements.  I.e if your add-on
module depends on gtk, you should say

  (use-modules (gtk2 gtk))

not

  (use-modules (gtk gtk))

Otherwise if you have a bunch of add-on modules (say not part of the
core guile distribution) installed that just called

  (use-modules (gtk gtk))

and then the local admin installs the brand new guile-gtk3_3.0-1*.deb
-- if this gtk3 package updates things so that (gtk gtk) now refers to
gtk3 instead of gtk2, then all of the add-on packages may break (if
they actually *needed* gtk2 and didn't know it.

Normal C libraries and apps avoid this problem, of course, by linking
to particular major version numbers of the libs they need so that
installing other versions doesn't affect them.

In our case, if all of those add-on packages had stated their
dependency explicitly via

  (use-modules (gtk2 gtk))

then installing the guile-gtk3_*.deb package wouldn't break anything
and gtk2 dependent packages and gtk3 dependend pacakges can coexist
peacefully.  Then the gtk2 dependent ones can then be upgraded to
handle gtk3 over time.  This is basically the same situation we have
with the libc5 -> libc6, ligmp2 -> libgmp3, etc. transitions.

The only drawback I can see with your suggested approach of just using
names with version numbers embedded in them rather than making the
VERSION/REVISION/AGE bits explicit on the provider side and the needed
REVISION explicit on the client side, is that there's no way to detect
when a newer version of a needed package is actually still OK

i.e. say gtk3 only added new interfaces -- it's still compatible with
the gtk2 API, then with more explict versioning, you can mention that
in the AGE parameter so that apps that

  (use-modules (gtk :version 2))

know they can safely load

  (define-modules (gtk :version 3 :age 1 :revision 12))

etc.

However, I'm not sure we really need that fine a grained control at
the guile .scm modules level, and frankly, I wonder how often the AGE
parameter ever comes in to play at the C level, but I thought I'd
mention it in case we do care.

> Right.  We might not be able to support using two versions of one
> library at the same time, however.  This would maybe work with
> plugin-style libraries that don't implicitely export C-level symbols
> to the rest of the program (linked with !RTLD_GLOBAL).  I think we
> should avoid using plugin-style libraries if possible.  Normal
> libraries can be used in more ways, I think (and are more
> conservative

Oh, right.  I forgot one bit that I'd tried to figure out how to put
in g-wrap.  I wanted to be able to detect dynamic load conflicts.
Given libtool and ldso's behavior, what happens if you try and load
two versions of the same shared lib from two different places (or two
different sub-libraries)?

> You would likely use different initialization functions here.
> "foo_init_scm" should always refer to the exact same function.  You
> might get away with reusing the name since ld.so does not seem to
> check for duplicate symbols (which it should IMO), but it's certainly
> bad style.

Oh right.  Sorry, I was just being sloppy.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930