[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release now?
From: |
Greg Troxel |
Subject: |
Re: Release now? |
Date: |
27 Feb 2003 14:25:09 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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.
- Re: Release now?, (continued)
- Re: Release now?, Marius Vollmer, 2003/02/25
- Re: Release now?, Greg Troxel, 2003/02/25
- Re: Release now?, Rob Browning, 2003/02/25
- Re: Release now?, Greg Troxel, 2003/02/25
- Re: Release now?, Rob Browning, 2003/02/25
- Re: Release now?, Greg Troxel, 2003/02/27
- pkg-config support for guile, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?,
Greg Troxel <=
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Greg Troxel, 2003/02/27
- Re: Release now?, Dale P. Smith, 2003/02/27
- Re: Release now?, Dale P. Smith, 2003/02/27
- Re: Release now?, Rob Browning, 2003/02/27
- Re: Release now?, Andreas Rottmann, 2003/02/25