Re: (in)stability / parallel installs / platform-2.7.93

[Andy Wingo]

Hi Greg,

First off, thanks for thinking about the proposal. I have an uneasy
feeling when doing this alone -- it's better to toss ideas around.

On Wed, 2004-10-27 at 11:30 -0400, Greg Troxel wrote:
> > API versions
> > ============
> 
> I'm not aware of what everybody else does.  Wrappers for libraries
> fundamentally have a version which is a tuple
>   < library-major#, library-minor#, wrapper-major#, wrapper-minor>
[...]
>   try very hard not to have to bump major.

Certainly.

>   bump minor with formal release if there are new procedures/variables

"major" == the "api version", e.g. guile-gnome-glib-0 -> 0
"minor" == the version of the package, e.g. guile-gnome-glib-0 -> 2.8.3

>   if the library has a major bump and this is reflected in the wrapper
>   api, bump wrapper major.  But this may not always be necessary,
>   since the scheme mapping might not change.

Yes, you summarized nicely. (Although I was initially confused, thinking
you were suggesting a direct mapping to .so versions, which wouldn't
work for dynamic-link.)

> > The load path
> > =============
> > It is clear that
> > different modules will have to live in disjoint load paths, and that the
> > load path will have to be munged at load time to pick the right one.
[...]
> Another approach is to name the modules
> 
> (gnome0 gobject)

This is *almost* the approach taken by glib1 and glib2. There are some
important differences though.

First, I doubt we will have as big a change in guile-gnome as between
glib1 and glib2.

Second. the version is picked in a glib1 vs. glib2 scenario when
compiling; in guile-gnome-1 vs. guile-gnome-2, you would have to go
through every source file and change "gnome1" to "gnome2", which invites
bugs. (Also consider bugs in scm_c_resolve_module, etc.) You're just
*asking* to accidentally include multiple versions of guile-gnome in the
same image.

Compare this to having the wrapper script do the "linking" to the proper
guile-gnome version -- given an accurate NEWS for the incompatible
break, it would be difficult to introduce bugs when moving to a
different version.

Last, with the name-change plan, changing the version would be hell for
me. Hell. Not only would all of guile-gnome's source code have to change
(including code generation modules), but the very names of the files
would have to change. That's ninth-level,
playing-with-satan's-frozen-beard hell.

> encoding the wrapper api version in the name, and in all the files.

The name isn't encoded in the files themselves for GLib. Both have
<glib.h>, just that pkg-config helps you choose at *compile time* which
one it is.

> > #! /bin/sh
> > exec guile-gnome-0 -s $0 "$@"
> > !#
> 
> This would solve the problem for gnome-gobject clients that run in a
> top-level guile interpreter.  But what happens when [...]

Admittedly a problem. You'd have to be able to do all that guile-gnome-0
does from C, I guess. It's a similar process to linking in C, and would
probably be done by pushing GUILE_GOBJECT_SCM_DIR onto the load path,
with -DGUILE_GOBECT_SCM_DIR=... when compiling. With regard to libs, see
below -- it's unclear.

> > Other files
> > ===========
> > 
> I have a strong aversion to setting LD_LIBRARY_PATH (doesn't work for
> suid, which is one of the problems).

For the record, Gtk+ won't work at all for suid. And isn't running #!
scripts suid insecure?

>   It's also totally unncesssary -
> a particular build of guile-gnome knows at configure time where the
> libraries are going,

I think I'm with you here, to a point. Certainly, any code that is
dynamic-link'd _and produced within guile-gnome_ can be referred to by
absolute path. The scheme code and C code are just too intertwined to
pretend otherwise. I changed the (gnome gobject ...) modules to do this
now, but g-wrap will need to change to get the generated scm files to do
this.

However, some guile-gnome C libraries link to other guile-gnome C
libraries. For example, the g-wrap generated dbus wrappers in
guile-gnome-extra will link to libguile-gnome-gobject, the core library,
which comes from guile-gnome-platform. Because libguile-gnome-gobject is
linked to, its name must be munged as libguile-gnome-gobject-0, and
installed in the normal $libdir. That is what is done now. But if you
are installing to a $libdir that isn't in the ld.so.conf path, you won't
pick it up. And I'm afraid that won't change -- if you install to a
wierd location, you do wierd environment hacks.

> > I'm not versioning info files right now. I'd like to avoid that, but
> > whatever. The only other problem now is pkg-config files.
> > Parallel-installed pkg-config files need to have different names, and
> > that sounds like automake pain, but it's probably necessary.
> 
> If you don't version info files, does that mean that one can only have
> one 'with info' version installed?  That seems like unnecessary grief
> for packagers, and a lack of orthogonality.

You're probably right...

> I also wonder if there is some way to use the guile module system to
> coat over using (gnome0 gobject) so that people who don't require a
> specific version can still say (gnome gobject).

Dunno. If the g-wrapped libs are linked by their absolute paths, yes.
Otherwise you will still have to munge the ld library path.

Regards,
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/