Re: Where to install files?

[Greg Troxel]

Neil Jerram <address@hidden> writes:

> Greg Troxel <address@hidden> writes:
> 
> Yes, thanks.  This is exactly what was in my mind too, but I didn't
> make that clear.

Glad I was helpful - was feeling redundant but posted anyway.

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

Agreed (for me it's NetBSD and pkgsrc).

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

NetBSD's take (speaking for myself, not The NetBSD Foundation - I am a
NetBSD developer) is that 

  /usr proper belongs to the base OS, and nothing else belongs there

  /usr/pkg belongs to pkgsrc, and only files installed/managed by
  pkgsrc belong there

  /usr/local is for people to do whatever they want with.  It's not in
  default includes/lib search path.

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

So specifically I think you mean

  guile installed under one prefix, probably by a packaging system

  some other guile-using package, e.g. guile-debugging, installed
  under some other prefix, but not using the packaging system.

If you configure guile-debugging with the same prefix as guile, these
issues become moot.  Thus my restriction to the different prefix case.

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

To me it's not a question of value.  /usr/pkg belongs to pkgsrc, and
to first order other stuff (meaning unmanaged and unrecord stuff)
should not be there.

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

Sure that makes sense, and another way is to have a standard, easy to
follow way to register additional load-path directories with the base
guile installation.

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

good point.

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

It's an autoconf (configure script really) directive, or perhaps one
that's commonly added, meant to specify where config files go,
defaulting to $(prefix)/etc or $(prefix)/etc/PACKAGE, but commonly
used to force things to /etc/PACKAGE, especially on systems where
people want that.

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

This notion of package/site/local is really just the obvious
generalization of the old site/local split, once one gets over
FreeBSD's misusing /usr/local for their ports system.

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

I kind of like having several standard places within a prefix, as seen
on NetBSD now:

guile> %load-path
("/usr/pkg/share/guile/site" "/usr/pkg/share/guile/1.6"
 "/usr/pkg/share/guile" ".")

Or rather, if that continues, I'd like to specify extra prefixes, with
the load path being the cross product of within-prefix places and
prefixes.  But perhaps also single dirs.

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

I don't follow that at all.

I'd like a load-path directory, with files whose names are irrelevant
but whose contets are dirs to add to the load path.  This is
pkg-friendly since they can be deleted and added automatically without
merge/editing issues, using the fs to represent set semantics.

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

sure, this is a way to avoid editing, so that a makefile can invoke the
'add prefix' method which would either be refcounted or idempotent.
All of this needs to be automation friendly.

-- 
        Greg Troxel <address@hidden>