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

>>>>> "Ben" == Ben Wing <[email protected]> writes:

Ben> >You're adding new stuff, so you're increasing complexity.

Ben> No.  I may be slightly increasing code complexity but I'm greatly
Ben> simplifying the situation from the perspective of a user.  See previous
Ben> comment.

I disagree.  You're adding a user-visible option without removing
another one.  You're doing this without any real indication from the
user community that you're solving an imminent problem.

Ben> An unfamiliar user should not have to use a hard, lower-level
Ben> interface.  They want an easy, high-level one.

An unfamiliar user should use neither of these options.  The familar
users don't seem to have a big problem.

Ben> Symlinks are a hack anyway

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

[--late-package-path]

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

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

Ben> Don't forget, in wanting to cater to the minority, that the vast majority of
Ben> users will put their packages in one place and have no site packages.  They
Ben> will want to say "You told me to put the packages under
Ben> /usr/local/lib/xemacs, but for one reason or another they can't go there so
Ben> I want to specify a directory in place of /usr/local/lib/xemacs".  I want
Ben> something that will do that.  How about:

I think that the vast majority of users don't need to tinker with the
package path at all.  And they shouldn't unless there's a strong
overriding reason to do so.

Ben> [a] Have a --late-package-path option that lets you specify the exact
Ben> locations of all package hierarchies.
Ben> [b] Also have a --late-package-prefix option that lets you specify the
Ben> directory under which the package hierarchies are located.  This is ignored
Ben> if --late-package-path is given, and otherwise creates a --late-package-path
Ben> using `xemacs-packages', `site-packages', `infodock-packages' (maybe), and
Ben> `mule-packages' (if compiled with Mule support).  This is less general than
Ben> --late-package-path but is much easier to use for the uninitiated, which
Ben> Will be 90% of new users out there.

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

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla