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

>>>>> "ms" == Michael Sperber <[email protected]> writes:

    Ben> Symlinks are a hack anyway

    ms> I disagree.  Symlinks are a pretty good mechanism for
    ms> expressing sharing in environments that have them.

OK.  You disagree.  Please remember that disagreement is a symmetric
relation, and therefore any "solution" based on symlink-oriented
thinking is going to be at best suspect, and quite likely
unacceptable, to Ben.

    ms> [--late-package-path]

    Ben> I would be fine with this if it's possible to specify a
    Ben> single directory, the directory containing xemacs-packages,
    Ben> mule-packages and the like (and have it automatically ignore
    Ben> mule-packages if we're a non-MULE build).

    ms> This may be OK if you used the existing infrastructure (in
    ms> `packages-compute-package-locations') for figuring these
    ms> things out; what you did was hard-wire things unnecessarily.

Mike, it _was_ necessary, and _you_ are primarily responsible for that.
For starters, `packages-compute-package-locations' is designed to make
this as difficult and opaque as possible, as you surely know.

package-compute-package-locations is very much an internal API (it has
a docstring, but is otherwise mentioned nowhere in the distribution,
except for two invocations), and the whole setup is documented as a
black box.  The only documented ways to affect its behavior are
--prefix, --package-path, and EMACSPACKAGEPATH---and those don't even
appear explicitly in the docstring!  The actual search algorithms
aren't even located in the same file.  You really have no ground to
complain that when Ben used what was apparently the recommended
interface he "unnecessarily" hard-coded things.  That's _your_ design,
not his!

As far as I can see, your agenda for years has been a fixed and frozen
hierarchy with a single root, and all pieces of XEmacs in their
well-known and eternally unchangeable places relative to that single
root.  Your love for symlinks is one manifestation: the idea is to use
the symlinks to fool XEmacs into thinking the packages are in their
Proper Places when in fact they're located in /root/alone/knows/lib/.

Now, I don't believe that you have deliberately concealed this, but
AFAICT the majority of XEmacs developers and users have a two-root
intuition.  There is the core root, and there is the package root
(which according to the intuition actually might be multiple, but is
singular for normal installations).

This divergence of intuitions results in a complete failure of
communication, because the minority intuition is the basis for the
actual design, but it is spelled out nowhere.

    Ben> They will want to say "You told me to put the packages under
    Ben> /usr/local/lib/xemacs, but for one reason or another they
    Ben> can't go there so I want to specify a directory in place of
    Ben> /usr/local/lib/xemacs".

    ms> I think that the vast majority of users don't need to tinker
    ms> with the package path at all.

I agree with this, strongly.  This is simply not a feature that
posters to c.e.x or xemacs-beta ask for.

    Ben> [a] Have a --late-package-path option that lets you specify
    Ben> the exact locations of all package hierarchies.  [b] Also
    Ben> have a --late-package-prefix option that lets you specify the
    Ben> directory under which the package hierarchies are located.
[...]

Those are horrible names.  Since configure almost by definition
doesn't need to be backward-compatible, just use --package-path and
--package-prefix (or --packages-path and --packages-root, which I like
better).

    ms> That would be fine, if nobody else disagrees with ditching
    ms> --package-path.  I think the way to do this with the least
    ms> possible friction would be if you let me do it.  If nobody
    ms> disagrees, I could get to work on the weekend or next week.
    ms> If I don't get it done by the end of next week, you can take
    ms> over.  Does that sound acceptable?

To be honest, that sounds disastrous to me.

I think this is recipe for more of the same, and merely postpones the
friction to a later date.  Since nobody but the cognoscenti use or ask
for this stuff at the moment, I don't see any hurry to implement this,
or (upon cooler reflection) to remove Ben's --package-prefix.  (I
still think it's a kludge that Ben of all people would be ashamed of
;-), but it's pretty harmless.)

I really really want a rationale document _first_, explaining what the
"ideal" XEmacs installation looks like, and why it looks that way, and
to what degree a "normal" installation may vary from the idea.  I
suspect many developers will be surprised by parts of it.

Among other things, I'm currently playing with the idea of reviving
the "last-packages" hierarchy for use by packages-in-source
distribution.  In general, I really think that there needs to be an
published and documented API for manipulating XEmacs's idea of the
package root, for use by installers and developers.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.