Re: Release now?

[Rob Browning]

Greg Troxel <address@hidden> writes:

> There is a large transition question, though - guile 1.6 already has
> libraries in a particular place.  For 1.8 to have a new place is
> probably fine, but this would be disruptive to those who have already
> found a satisfactory solution.  Hence my notion of having the
> version-named midfix be optional, so Debian can use it and NetBSD can
> keep using separate prefixes.

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

> Also, we might consider having a different prefix rather than a
> 'midfix', which seems awkward.  With /usr/lib/guile/1.4, guile/1.4
> gets appended to $(libdir).  The alternative of /usr/guile/1.4/lib,
> where prefix is /usr/guile/1.4 instead of /usr, seems cleaner to me.

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.

> Summarizing:
>
>   If the installed locations of guile 1.6 changes, I object because it
>   will cause work for people who have already coped.

Hmm, but I'm only talking about changing the location of one file (a
symlink) on the lib side, per library, i.e. libguile.so, which would
affect packagers, but shouldn't affect anyone using guile-config.

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.

>   I prefer the different prefix rather than a midfix.  A configure
>   option to add a midfix seems ok, but given that we already have
>   --prefix, it seems like more work.

I don't really think this is likely to be acceptable as a default.  If
you've ever seen the mass objections from *many* unix camps to
attempts to violate the FHS-style /usr/lib/*, /usr/include/* approach,
you know what I mean.  I can understand -- there are good reasons for
many of the choices made in the FHS.

That doesn't mean we shouldn't have a way to support other
approaches.  In gnucash we had --enable-opt-style-install.  I don't
think I'd want to name the option that now, but it arranged for things
to be /etc/gnucash/blarg by default, but to be able to be
/opt/gnucash/etc/blarg when requested.  It was somewhat a pain to
arrange and maintain, but it can be done.

>   If the default behavior includes either midfixes or extra symlinks,
>   I object, because it is imposing what some may view as uncleanliness
>   on everyone because some decline to use -R.

I think we may just have to agree to disagree here.  From the user's
perspective, the -L approach should be transparent, and from anyone
else's perspective, it should be trivial to either support a
--configure option that changes that default, or just let them "mv
guilelibdir/* libdir/" in whatever build/install script/infrastructure
they're using.  Or we could possibly have an option.

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.

>   Differing prefixes and a ./configure option to symlink into another
>   prefix is a clean solution

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.

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.

And although we may want to do it anyway, having more than one
strategy, especially if they're significantly different, does increase
the support burden both on the coding side, and on the end-user side.

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