Re: Release now?

[Rob Browning <rlb@defaultvalue.org>]

Greg Troxel <gdt@ir.bbn.com> writes:

> But, running 'pkg-config --use-version 1.6' should be no different
> than guile16-config, except that it's easier to write configure.in
> fragments.  It does mean we get to sidestep the issue about which
> guile-config is 'primary' and which has a version number.  But I'm
> not sure that's a huge issue - the latest can be primary and the
> others have the number.

Or you can do something like Debian's update-alternatives -- have a
priority system, but allow for the local maintainer to override...

FWIW, as far as I can tell, the only way we can allow compilation for
multiple versions of guile is if we don't put the libs into /usr/lib
with the other libraries.  Either that, or we have to put our major
version number into the library name.

In fact we wouldn't be able to put *any* libguile.so into /usr/lib,
otherwise *any* other package's foo-config script that put a
-L/usr/lib on the gcc command line could cause us to get the wrong
one, even if the gcc command line also contained the output of an
invocation of guile-X.Y-config somewhere.

Another consideration (and perhaps everyone is still aware of) is that
of -rpath.  There are many who are opposed to it, and without it, you
don't really have any way to put guile's libs anywhere but /usr/lib or
similar...

Hmm, now that I think about it, I wonder if systems could handle just
having the .so links off in a subdir, i.e. put libguile.so in
/usr/lib/guile/VERSION, but put the actual libguile libs in /usr/lib.
This might avoid the need for an -rpath, LD_LIBRARY_PATH, or any
changes to ld.so.conf, but still allow specifying a particular guile
with -L/usr/lib/guile/VERSION.  Hmm...  Thoughts?

> The NetBSD pkgsrc approach means that when one compiles guile-gtk,
> for instance, one could put the 1.4-linked version in
> /usr/pkg/guile/1.4 and the 1.6 version in /usr/pkg.  Do you really
> mean pure Scheme code, or stuff with dynlibs?  I would think that
> pure Scheme code could feature-test and cope - is this really an
> issue?

Personally I feel like it is.  To me it seems like just as much an
issue as it is for binary shared libraries.  A module presents an
interface, and that interface may change over time.  So the client
should have some way to ask for a particular "version" of that
interface i.e. (use-modules (postgresql-fancy #:interface 3)).  Of
course, others may differ and feel like we should just leave this up
to the author and client to come up with their own scheme,
i.e. checking version number, defined?, etc.  Though note that I'm not
sure we've settled the future of some of the features like defined?.

I'd tend to lean towards having a standard strategy like #:interface
or maybe #:version for people to use.  They can always ignore it and
invent their own custom strategies using (use-modules (foo)) if they
want.  I'm open to being convinced otherwise, though.

> But, this all points out the really serious extended consequences of
> not maintaining _compile-time_ backwards compatibility.  I'm not
> (personally) at all worried about running old binaries with newer
> guile libraries.  The issue is whether programs that compile against
> guile can just work when the system's base guile version is
> upgraded.

Perhaps I'm misunderstanding.  If the soname hasn't changed, then you
should be fine.  If it has, then you have to recompile...  Also,
unless we can *prove* that nothing has changed in a way that would
break backward compatibility, we have to change the soname with each
major release.

Also I guess we need to be clear what the C lib sonames mean.  Do they
also reflect the indirect "API" available from ice-9 via scm_c_eval?
For example, if we had a function in ice-9 called (get-blarg) that
returned `(,foo . ,bar), and we change it so that it returns `(,bar
. ,foo), then do we have to change the libguile version number since
since C code could access this via scm_c_eval?  Perhaps, perhaps not,
but I think we should figure this out and make a clear statement in
the docs.

> We've seen a lot of pain (and non-upgrading of guile in major
> distributions) recently.

As far as I can tell, this is always going to be true to some extent,
though we should do our best to minimize it.  I've seen it happen for
perl and python regularly, and I'd expect our situation to be worse
(and it is) because of our unique requirement that users be able to
link directly to our libraries from C, and that of course leads to
libs linked to libs linked to guile and the whole "indirect linkage to
two versions of libguile" problem.

> So, ensuring that 1.8 is a drop-in replacement for 1.6 would be good,

If you mean drop-in as in "just requires a recompile of things linked
against it", then I suspect that's quite possible.  If you mean
"doesn't even require recompile", then I at least somewhat doubt it.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel