Neil Jerram <[EMAIL PROTECTED]> writes:
> Greg Troxel <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
