[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where to install files?
Re: Where to install files?
Tue, 11 Oct 2005 19:42:55 +0100
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
Greg Troxel <address@hidden> writes:
> I concur with most of your comments, but would like to make a
> metapoint: various OS/distributions/packaging systems have rules about
> what goes where, and guile should be such that it can be made to
> behave 'right' for these varying definitions of right. I think this
> is implicit in your comments, but wanted to raise it explicitly.
Yes, thanks. This is exactly what was in my mind too, but I didn't
make that clear.
Basically, when I'm using a distribution (Debian in my case), I like
to do things as much as possible in the way that that distribution
designed. And I would hope that distributions are broad-minded (or
control-freak!) enough to have a policy on where
non-distribution-managed stuff should go.
> All that said, most packaging systems (pkgsrc, FreeBSD ports, typical
> Linux) put all programs under the same prefix, so using "guile's
> prefix" vs "our prefix" amounts to the same thing. So it's only
> non-distribution-managed that's an issue.
Yes, exactly. And the non-distribution-managed part is foremost in my
mind right now, because the load-path issue just came up with someone
installing my guile-debugging package, which is so far only available
as a tarball.
> My own view is that a package configured with --prefix=/usr/foo should
> install files only under /usr/foo. This leads me with guile to want
> to extend load-path to include guile directories in other prefixes.
On this point I think I disagree with you. I think there is value in
forcing all packages to be loaded - or at least bootstrapped - from a
known load-path that is defined by the Guile installation.
Note that this doesn't _force_ all Scheme files to go under one of the
load-path locations. A big application like Gnucash could put a
bootstrap file like this in one of the standard locations ...
(set! %load-path (cons "/opt/gnucash" %load-path))
(use-modules (gnucash account)
... and then all its other Scheme files under /opt/gnucash.
IMO this is good because everything is explicit and there is a nice
trail for the investigative free software developer to follow when
they want to understand how stuff works.
> (5) location of the system init file (e.g. /etc/guile/1.6/init.scm,
> Using --sysconfdir to specify this is/would be nice, and would make it
> easy to hook in a new prefix.
I'm sure you're right, but what is it that defines sysconfdir, and
where can I read about how it behaves?
> Guile's guile.m4 currently provides GUILE_SITE_DIR, but that feels
> wrong to me both because it doesn't handle the (2)/(3) distinction
> above, and because of the /site ending - I think of site as being for
> code put there by the local sysadmin, not for code from packages at
> I agree, but really we need three levels:
> pkgsrc [wrong word, but distribution-managed]
> site [managed for a group of machines]
> local [just this machine]
Are you sure you're not a plant in the audience? Your levels idea
connects perfectly with a generalization of the scheme I described
yesterday, which occurred to me after posting:
- At Guile configuration time, we allow the builder to specify an
arbitrary set of load path directories, each with a tag and a
description, something (semantically speaking) like this:
"Install location for Guile 1.6's own Scheme files")
"Install location for site-specific Scheme files")
"Install location for GNOME-related Scheme files")
"Version-independent non-distribution-managed Scheme files")
"1.6-dependent non-distribution-managed Scheme files"))
- Guile would always then initialize its %load-path to the union of
all these locations.
- guile.m4 would provide a --with-guile-scheme-dir=TAG option to
./configure, which would set GUILE_SCHEME_DIR to the location for
TAG, and a macro
which a package would put in its configure.in, with default-tag
specifying the tag to use if --with-guile-scheme-dir is not
--with-guile-scheme-dir could also specify a directory explicitly.
Actually it may not be necessary to specify the location list above at
Guile configuration time; the list could perhaps go into init.scm, or
another init file (in sysconfdir) which is always read, even if Guile
is given a -no-init-file option.
> With respect to /usr/local, I believe that guile should by default
> only look in its own prefix. Whether /usr/local should be searched
> e.g by programs in /usr is a distribution-specific decision. It may
> be worthwhile to have a configure argument to add prefixes whose guile
> directories should be searched, so that
> ./configure --prefix=/usr/pkg --searchprefix=/usr/bar
> would result in a guile installed in /usr/pkg that not only looks in
> /usr/pkg/share/guile/1.6 but also /usr/bar/share/guile/1.6.
Yes; I think this is equivalent to what I've just described, though.
> It might also be nice to have a run-time method to
> guile-configer --addsearchprefix=/usr/bar
> so that someone building another package to /usr/bar can invoke this
> on the system guile to hook in the new path.
In my view the behaviour that this allows is sufficiently covered by
the combination of
- being able to edit init.scm (or other init file, per comment above)
- the bootstrapping approach described above.
So I don't think we need this as well, at least not in the core
mechanism. (A distribution or sysadmin could choose to implement this
for their distribution/systems by organizing their init.scm