1.6, Guile's shared libraries, Debian packaging, and versioning.

* 1.6, Guile's shared libraries, Debian packaging, and versioning.
@ 2002-07-20 18:40 Rob Browning
  2002-07-21 23:45 ` Han-Wen
  0 siblings, 1 reply; 5+ messages in thread
From: Rob Browning @ 2002-07-20 18:40 UTC (permalink / raw)

It looks like I'll be releasing the next 1.5 beta today or tomorrow.
Note that this means that 1.6.1 will be released in about 2 weeks
unless there are release critical bugs.

One thing that had been holding me up for the past few days was trying
to think through versioning issues wrt guile itself, our shared libs,
and other external apps and libs linked against guile.  In particular,
I was still trying to think through things enough to feel reasonably
comfortable that the way we have things now can be packaged (say via
.debs) for 1.6 in a way that won't cause trouble when we release 1.8.

The questions involved are ones like, "What are the actual
interdependencies between our scheme modules and our shared libs?"
"When is it OK to break API compatibility?"  "Are shared libraries
allowed to depend on .scm modules?  If so, then what policies are
required to make sure that new guile installations don't break apps
linked against older versions of guile?".  i.e. it needs to be safe to
install guile 1.8 (or even later versions of 1.6.X) without breaking
all the apps linked against 1.6.1.

As a concrete example of a problem -- imagine we release guile-1.6.1
with libguile-12 and libguile-foo-1 and application app-bar links
against both, libguile because it needs to call scm_init_guile, and
libguile-foo-1 because it needs foo_frob.  So we have:

  app-bar
    libguile.so.12 -> /usr/bin/libguile.so.12
    libguile-foo-1.so.1 -> /usr/bin/libguile-foo-1.so.1.0.0

  libguile-foo-1
    libguile.so.12 -> /usr/bin/libguile.so.12

now imagine we release a guile with libguile-13.  libguile-foo-1 has
to be recompiled because against libguile-13, but now that means that
without if we don't recompile app-bar at the same time, we'll have:

  app-bar
    libguile.so.12 -> /usr/bin/libguile.so.12
    libguile-foo-1.so.1 -> /usr/bin/libguile-foo-1.so.1.0.0

  libguile-foo-1
    libguile.so.13 -> /usr/bin/libguile.so.13

Is that OK?  If not, then what that says is that changing libguile's
major number means that we (and everyone else) has to bump the major
version numbers of all libraries linked against libguile whenever we
bump the major version number of libguile so you can have the old
app-bar and a new app-baz which is linked against libguile-13 on the
same system which would look like this:

  app-bar
    libguile.so.12 -> /usr/bin/libguile.so.12
    libguile-foo-1.so.1 -> /usr/bin/libguile-foo-1.so.1.0.0

  libguile-foo-1
    libguile.so.12 -> /usr/bin/libguile.so.12

  app-bar
    libguile.so.12 -> /usr/bin/libguile.so.12
    libguile-foo-2.so.1 -> /usr/bin/libguile-foo-2.so.1.0.0

  libguile-foo-2
    libguile.so.13 -> /usr/bin/libguile.so.13

If that's right, then there might be a lot less reason not to just
have something less complex.

  /usr/lib/libguile.so.12.0.1
  /usr/lib/guile/12/libsrfi-4.so
  /usr/lib/guile/12/libpg-interface.so
  /usr/lib/guile/12/libsomething-else.so

which makes the issue clear in the filesystem.  At least this was the
other debian maintainer's suggestion -- though we don't have to do
that.  We could just make a policy that all libs linked against a
particular version of libguile have to bump their major version
whenever a new libguile comes out.  Not as explicit, and perhaps a
little harder to make sure it's enforced, but probably also correct.

Not sure which policy is better ATM, but I feel like we do need some
clear policies.

There are similar issues we have to decide regarding a shared
libraries acceptable use of .scm files, and how to package those .scm
files so they can stick with the versions of the libraries that depend
on them (if we decide that libraries can in fact depend on .scm files)
whenever multiple versions of the library are installed on the system.

In any case, I'm happy to let this lie for now -- I'm going to get
1.6.1 out, and get it packaged for Debian in a fairly simple-minded
way, but I'll want to revisit the topic in detail in 1.7.

Thanks.

-- 
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

^ permalink raw reply	[flat|nested] 5+ messages in thread