Re: The load path

[Rob Browning]

address@hidden (Paul Jarc) writes:

> I like this idea.  But there should probably be a command-line
> switch to disable loading these files.  For a parallel example with
> Emacs, sometimes there is a site installation of Gnus, and the site
> init files load part of Gnus, but the user may have their own newer
> copy of Gnus that they want to use.  So they should be able to (and
> with Emacs, they can) disable the normal loading of the site init
> files, and then explicitly load them from their personal init file
> after they've made the necessary load-path changes.

Hmm.  We were thinking of having guile load from
${sysconfdir}/guile-X.Y/init.d/.  If the local version isn't installed
in the same place as the site installation, then it wouldn't try to
load the site's files by default.  However, if you did want it to load
them, you could just create a symlink to init.d, or make the init call
yourself.

Even so, perhaps a "--site-files DIR" option might be worth
considering.

> I'm not sure the two-digit requirement will be useful.  Independent
> packages won't know about each other, so they have no way to guess
> the right order for their init files to be loaded in.  They should
> aim for order-independence.  Then if it turns out there are ordering
> problems, the admin can create earlier-named symlinks that fall in
> the right order, and Guile can say "I've seen this device+inode
> before, I won't load it again".

(minor note: I had been thinking of one or more digits.)

We were modeling this after the normal sysvinit and Debian emacsen
approach.  i.e. /etc/rcS.d/ and /etc/emacs/site-start.d/.  Using
NUMBERname makes it very easy to predict what's going to happen.  With
the device+inode+visited-table approach, you can't easily tell what's
going to happen just by looking at the directory.

On the other hand, I can see the concern that the NUMBERname approach
is perhaps best suited for a situation where you have centralized
organization (i.e. a distribution).

We probably need a bit of further consideration here.

As background, one of the original reasons for our proposed changes is
to provide a standard place for distributions to put add-on package
files (a la emacs/site-start.d/).  The fact that this also lets us
move the site initialization file (init.scm) to /etc/ (by reserving
N*site-local.scm) is an added benefit that fixes a violation of the
FHS.

> That check would also let packages' init files load other init files
> they depend on, which solves the ordering problem automatically,
> without having to guess numbers.

That might argue for a use-modules or require/provide style solution,
though if appropriate, we'd want a modified one that only looks in the
init.d dir so that startup files can't be confused with files in other
packages (i.e. don't use load-path).

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4