Re: packaging the add-on libs...

[Greg Troxel <gdt@ir.bbn.com>]

  It's not just the compilation issue.  To take your libc example, the
  issue in question is what happens if app blarg uses both libfoo1 and
  libbar1, and both of these are compiled against libc6, and then libc7
  comes out.  Say shortly thereafter libfoo2 comes out, compiled against
  libc7.  If blarg is now recompiled, it'll get libfoo2 and libbar1 and
  hence will be indirectly linked against both libc6 and libc7
  until/unless a new libfoo comes out that's linked against libc7.

  Is the answer "well, then blarg will just have a potential problem
  until libbar is updated"?

I don't think we can solve everything.  But here, if one rebuilds all
the packages from source, libbar1 will get linked against libc7 and
things will be ok.

  The transition period would consist of the time between when a new
  libguileX comes out, and when all the "add-on libs" that depend on the
  old version of libguile are rebuilt against the new version of guile.
  Actually it's only the add-on libs that are actually used by some
  other app or lib that also uses some other add-on lib that cause
  trouble, but we can't predict that.

A bit of pain while guile add-ons are revved is one thing, but I would
really like to avoid pain on guile-using apps, since they'll just
stop.  guile add-on writers are guile weenies who will not give up so
easily.

  glib's only a good example if you consider it in a broader context.
  Imagine after glib 2.0 is released, libgnome-vfs has been upgraded to
  compile against glib 2.0 but libgnome-print has not.  Where does this
  leave evolution when it recompiles (presuming it links against both
  libs)?

This leaves evolution broken, I think.  I think the gnome folks may
create libgnome-vfs2, so that gnome2 apps can use that, and the older
apps can use libgnome-vfs.  As an example, orbit2 uses glib 2.0, so
when switching from glib 1.2 to glib 2.0, one switches to orbit2.
This would be easier if f.i. guile-gtk went under
$(prefix)/share/guile/1.6 rather than $(prefix)/share/guile directly.
But, I don't think such add-ons are super critical in terms of total
pain and worry about guile market share loss.

I agree that the problem is not completely solveable.  But, I think
the real question is

  What can guile do that minimizes pain to people who write
  applications using guile, and people that maintains
  pkgsrc/ports/deb/rpm of such programs and guile itself.

(For what it's worth, I have guile 1.6 installed in /usr/projectname
for a project I'm working on that uses a guile-gtk GUI to monitor
things.  This doesn't conflict with /usr/pkg/bin/guile, which is 1.4
for gnome etc., as long as I use the change to look up helper libs at
absolute pathnames.  But a different prefix isn't ok for NetBSD's
pkgsrc, and I bet it's not ok for Debian either.)

        Greg Troxel <gdt@ir.bbn.com>


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