RE: [VETO] Support package-prefix and fix mail-locking in configure

> And round and round we go.  You complain about the 
> documentation, I ask for clarification, you complain about 
> the design, I try to explain the design, you complain about 
> the documentation, and we go back to step 1.  That's exactly 
> what we've been doing for years.  It just isn't helpful 
> information for me, if I want to provide something that'll 
> make more sense to you.  That may very well be a failing of 
> mine, but so there.
> 
> XEmacs can deal with the packages in a different location 
> from the rest just fine: that's why `emacs-roots' is a list, 
> and not a string. Maybe it isn't configurable in the way you 
> want, but the conceptual machinery is all there.  Maybe 
> that's how we need to attack the problem.

OK, I'm going to inject my two cents in here, although I haven't read all
the latest messages entirely.

But I understand very clearly what Stephen is saying, and I agree with it.

[1] Conceptually there should be two kinds of roots: Core roots, and package
roots.

[2] A core root is a directory under which you find bin/xemacs.exe, info/*,
man/*, etc; or src/xemacs.exe, etc. in a run-from-source configuration.

[3] A package root is a directory under which you find `xemacs-packages',
`mule-packages', etc.

[4] Generally there should be one core root (I can't think of an obvious
case where there should be more than one), but potentially many package
roots.

[5] The core root is determined at runtime by some sort of magic.

[6] The set of package roots is determined at runtime by combining
    some standard locations with any package roots specified using
    --package-prefix, in the following order, where earlier in the
    list means earlier in the load-path:

    [1] ~/.xemacs
    [2] [maybe] an environment variable EMACSPACKAGEPREFIX
    [3] --package-prefix
    [4] CORE-ROOT/lib/xemacs-VERSION
    [5] CORE-ROOT/lib/xemacs

[Note that parallelism between --prefix, which specifies the core root, and
--package-prefix, which specifies the package roots.]

[7] --package-path and EMACSPACKAGEPATH should be removed, as should the
confusing concepts of "early", "late", and "last", which are false
generality.

[8] The code should be [a] modified to work as above, [b] documented, since
most of the routines are not documented at all, [c] cleaned of all
unnecessary goop, of which there is quite a lot.

[9] The docs should be rewritten to reflect the above description.