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

[Greg Troxel]

Andy Wingo <address@hidden> writes:

> Take a look at the rules:
> http://developer.gnome.org/dotplan/bindings/rules.html

Wow, the GNOME train purports to run on time!

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

It seems that library major is very stable these days, and library
minor is fairly stable.  We only need to bump wrapper-major on
incompatible changes, and wrapper minor when adding procedures.  Minor
bumps will happen all the time as we gain coverage of existing gnome
procedures.

So, I think your plan of using the wrapper major/minor makes sense,
with the additional caveats:
  try very hard not to have to bump major.
  bump minor with formal release if there are new procedures/variables

  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.

> The load path
> =============
> 
> In the context of multiple versions of an API installed, using the
> (gnome gobject) module has no defined meaning.

Agreed.

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

I don't think this is at all clear.  The requirements are that one can
install both (and use either, as well as build programs that rely on
either).  Setting up the modules in distinct prefixes/load paths is
one approach.

Another approach is to name the modules

(gnome0 gobject)

encoding the wrapper api version in the name, and in all the files.
This is the approach taken by glib1 and glib2, and IMHO it is has been
spectacularly successful: tons of people have both installed, and
there has been essentially no grief from this.

> I think that this can be done nicely with a wrapper script, e.g. for API
> version 0 it would be `guile-gnome-0'. Running the script would set up
> the guile load path as appropriate, and then exec guile, passing on all
> of its arguments. A script written for guile-gnome-0 would then start
> like this:
> 
> #! /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 I add guile
support to postfix, and then write something in scheme that uses
guile-gobject's corba support to query some other process?

> Other files
> ===========
> 
> Requiring a wrapper script has the added ability to munge
> LD_LIBRARY_PATH, so that g-wrapped libs can be put in
> $libdir/guile-gnome-$apiversion. There's still a problem with the base
> gobject wrapper (and corba as well), which are actually linked to. These
> need to have their names munged, much like there is libgtk-1.2 and
> libgtk-x11-2.0. I have $libdir/libguile-gnome-gobject-$apiversion.so.
> Headers are likewise installed in versioned directories, which are
> pointed to by the pkg-config files.

I have a strong aversion to setting LD_LIBRARY_PATH (doesn't work for
suid, which is one of the problems).  It's also totally unncesssary -
a particular build of guile-gnome knows at configure time where the
libraries are going, and can simply use the full path in the
dynamic-link call.  This is similar, but has the advantage of
precision in that a) the path is only used for the libraries that need
it and b) those libraries are looked for in only the correct place,
and nowhere else.

> 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.  It seems unclean to have
several different mechanisms to choose the appropriate file.

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

-- 
        Greg Troxel <address@hidden>