Re: Release now?

[Rob Browning]

Greg Troxel <address@hidden> writes:

> This makes sense.  But, I'd lean hard to trying not to change such
> interfaces by adding new names and deprecating old procedures over time.
> Also, I'm not sure this is causing us pain, and I somewhat lean in the
> direction of only favoring complex mechanisms to avoid actual or
> near-term expected pain.

I think I tend to look at it as setting up infrastructure now that
encourages people to do things that may save anguish later, but I can
also see your point.

Though I did have the semi-amusing idea of trying to make guile nearly
all modules (which I think I've mentioned before), i.e.

  #!/usr/bin/guile-strap -s \
  !#
  (use-modules (ice-9 core #:interface 6))
  ...

I think it's probably simpler and more obviously useful to just
standardize our naming convention.  I'm inclined to change the
unstable tree to install guile as guile-X.Y from now on, along with
all the other tools, and have an easily bypassable inst-hook (or
similar) that sets up the default links:

  cd ${bindir} && ln -sf guile-X.Y guile

I might also try to make another install target that didn't set up the
links, perhaps "make install-no-convenience-links" or whatever.

This would allow people to reliably start writing #!/usr/bin/guile-1.6
scripts, or maybe more portably

  #!/bin/sh
  exec guile-1.6 "$@"

> If someone is unwilling to use -rpath and unwilling to use
> LD_LIBRARY_PATH, then yes, guile's libs need to be in /usr/lib.  guile
> can be built with --prefix=/usr, so this is supported.  This makes it
> hard to have two versions unless all libs have versions in the names.
> I'm not sure how hard it would be to make /usr/lib/libguile16.so.15
> and /usr/lib/libguile14.so.10 instead - and I'm not sure what it would
> hurt.  (An example is glib 1.2 and 2.0.)

What do you think about my other suggestion?  i.e.

  - put libguile.so.*, etc. in /usr/lib (i.e. ${libdir})
  - put the libguile.so development symlinks (i.e. the ones -l uses)
    in /usr/lib/guile/VERSION
  - put the headers in /usr/include/guile/VERSION
  - require the use of guile-config and arrange for guile-config to
    spit out -I/usr/include/guile/VERSION and -L/usr/lib/guile/VERSION
    when appropriate

So far this seems to me like it might solve the "allow multiple
development versions to be installed" problem without requiring
-rpath, LD_LIBRARY_PATH, or ld.so.conf modifications, but I haven't
been thinking about it for long yet.  If this *would* work, I can
implement it in CVS, and adjust Debian accordingly...

Basically gcc -lguile would find the libguile.so in
/usr/lib/guile/VERSION/ via the -L argument from guile-X.Y-config, and
would use that to embed the right SONAME into the app or lib being
built.  Then at runtime, the linker would find the newest suitable
version, say libguile.so.12.0.1 in /usr/lib/.

> But I wasn't talking about this - I meant compatibility at the
> source/build level, not dynamically linking the new .so into an old
> binary.  The real pain has happened because one couldn't in general
> take a program that built against guile 1.4 and just replace guile
> with 1.6 and rebuild it from scratch.

I won't argue that the 1.4 -> 1.6 transition was possibly somewhat
jarring.  While I still feel like many of those changes were
worthwhile and will serve us well going forward, I think that we're
likely to do that less often going forward.  As Marius has mentioned,
we'll be restoring a number of things in CVS that had already been
removed in preparation for 1.8.

> Thanks for thinking about this - I think it is critical to promoting
> guile acceptance and use.

You and I both :>

Though guile's particular objectives do provide some fairly
"challenging" constraints on the possible solutions.

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