Re: Release now?

[Greg Troxel]

  Though at least for end-users compiling using guile-config, I'd hope
  the transition would be rather painless.

I think I'm almost convinced (and almost is enough) that's true.

  I don't really think that's feasible, at least not as the default.  At
  least for most of the linux distributions (and I'd guess solaris,
  etc.) that would be in contravention of the FHS (and predecessors),
  and I would guess also the LSB.

I just went and read parts of FHS, so I see your point on this.
That said, GNU software supports letting the user choose the prefix,
and we shouldn't lose that, but if our interpretion of where things
belong under the prefix includes versioned subdirs that's OK.

  Also we're going to *have* to change the install location of the
  headers, i.e. /usr/include/guile/VERSION/, at least for normal
  autoconf style installs, i.e. FHS compliant installs since using
  /usr/include/libguile.h doesn't allow multiple dev versions to be
  installed.

Either that or multiple prefixes, and I see that multiple prefixes are
frowned upon by the FHS.  Since there is no proposal on the table to
remove the ability to use --prefix, that's not an issue.

  If what you're arguing for is in fact an "opt-style" install, then
  that's fine, but I think it'll have to be something that can be
  enabled rather than the default since it's my impression that FHS
  style layouts are the definite majority.

I was asking for the current bebavior to be preserved unless someone
asks for --version-dirs, which would put things in /usr/lib/guile/1.x
instead of /usr/lib (and similarly for /usr/share, etc.).  But I guess
that really isn't necessary, as long as guile-config-using software
can just rebuild and run.  So I withdraw this objection.

  I think maybe I still don't have a good impression of what you're
  preferred solution is (and that's likely my fault) -- I'm not sure
  what the "prefixes" are here.

I meant:
guile14-src $ ./configure --prefix=/usr/pkg/guile/1.4
guile16-src $ ./configure --prefix=/usr/pkg/guile/1.6
guile18-src $ ./configure --prefix=/usr/pkg/guile/1.8
or perhaps one of them being the 'primary' and installed in /usr/pkg
directly.  But I see how this violate FHS and how people might not
like it.  And I  realize it causes problems in a rpath-prohibited
environment.

  Overall, I still feel like the changes I've proposed are a fairly
  small alteration to the current strategy, and seem to be likely to
  work everywhere.  That's what's driving my immediate inclination.

I may be overestimating their impact.  Perhaps if you wrote down
precisely what files would get installed in different places, and what
extra symlinks would be made (and under what circumstances) this would
all be clearer.  I just looked through what is in the 1.6 pkg, and see
a bunch of things.  I'll list them and annotate with what I think you
are proposing.  Except that I don't get what you mean for libs, so I
listed what came to me as I was doing this exercise.

Then, it would be good to understand the ripple effects on e.g. having
guile-gtk for two guile versions installed - can that just adopt the
same scheme?

bin/guile
bin/guile-snarf
bin/guile-config
bin/guile-tools
  put in bin/guile/X.Y, and symlink one to bin/guile
  presumably  the "I want the symlink in the standard place" is a
  configure option, so it can be assigned to the package denoted as
  primary by the package system maintainer.  Use --primary-symlinks as
  the configure option, perhaps.

include/libguile/__scm.h
[...]
include/guile/gh.h
include/guile/srfi/srfi-4.h
include/guile/srfi/srfi-13.h
include/guile/srfi/srfi-14.h
include/guile-readline/readline.h
include/libguile.h
  put in include/guile/X.Y/{libguile/*,guile/*,libguile.h}, with no symlinks.
  people should be using guile-config/pkgconfig, so there is no need
  to have anything work  unless the appropiate
  -I/usr/include/guile/1.4 is given.

info/guile.info
info/guile.info-1
[...]
  put in info/guile/X.Y/*, with symlinks from info if the
  --primary-symlinks option was given.  This makes them all available
  and the primary obtained by default.

lib/libguile.a
lib/libguile.la
lib/libguile.so
lib/libguile.so.15
lib/libguile.so.15.0
lib/libguile-ltdl.a
lib/libguile-ltdl.la
lib/libguile-ltdl.so
lib/libguile-ltdl.so.1
lib/libguile-ltdl.so.1.0
lib/libguilereadline-v-12.a
lib/libguilereadline-v-12.la
lib/libguilereadline-v-12.so
lib/libguilereadline-v-12.so.15
lib/libguilereadline-v-12.so.15.0
lib/libguile-srfi-srfi-4-v-1.a
lib/libguile-srfi-srfi-4-v-1.la
lib/libguile-srfi-srfi-4-v-1.so
lib/libguile-srfi-srfi-4-v-1.so.1
lib/libguile-srfi-srfi-4-v-1.so.1.0
lib/libguile-srfi-srfi-13-14-v-1.a
lib/libguile-srfi-srfi-13-14-v-1.la
lib/libguile-srfi-srfi-13-14-v-1.so
lib/libguile-srfi-srfi-13-14-v-1.so.1
lib/libguile-srfi-srfi-13-14-v-1.so.1.0
  put in lib/guile/X.Y
  symlinks for libguile.so.15/15.0 and other libs into lib/
  symlinks for libguile.a/libguile.la (?) if --primary-symlinks
  never a symlink in lib for libguile.so itself

  err, now I realize this isn't what you mean.  I think you have
  proposed putting the .sos with versions in $(prefix)/lib, and
  symlinks for libguile.so in the special link-time-only lib.  But I
  don't understand where the .a and .la versions go - is the
  /usr/lib/guile/X.Y scheme primary, or not?  With include files, it
  is primary, and it's only an accident of so naming that they don't
  collide for some cases.

  how about /usr/lib has no guile files, unless
  --lib-symlinks
  is given?  Then the rpath users will have a clean separation, and
  those without rpath can pick up libguile.so.{9,10,15} from /usr/lib.

share/aclocal/guile.m4
  put in share/guile/1.4/aclocal/guile.m4
  symlink in share/aclocal if --primary-symlinks

share/guile/1.6/oop/goops/active-slot.scm
[...]
  already versioned.  No changes needed.


So I realize now that I don't understand what you propose in terms of
moving libraries.