Re: Where to install files?

[Neil Jerram]

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

(define-module (gnucash))

(set! %load-path (cons "/opt/gnucash" %load-path))

(use-modules (gnucash account)
             (gnucash ui)
             ...)

... 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,
>       default=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
>   all.
>
> 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:

  '(("/usr/share/guile/1.6"
     "1.6"
     "Install location for Guile 1.6's own Scheme files")

    ("/usr/share/guile/site"
     "site"
     "Install location for site-specific Scheme files")

    ("/opt/gnome/guile"
     "gnome"
     "Install location for GNOME-related Scheme files")

    ("/usr/local/share/guile"
     "local"
     "Version-independent non-distribution-managed Scheme files")

    ("/usr/local/share/guile/1.6"
     "local-1.6"
     "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

    GUILE_SCHEME(default-tag)

  which a package would put in its configure.in, with default-tag
  specifying the tag to use if --with-guile-scheme-dir is not
  specified.

  --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 
> --searchprefix=/usr/baz
>
> 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
appropriately.)

Regards,
     Neil