>>>> "Pema" == Pekka Marjola <pema(a)iki.fi>
Pema> What's the point of with-package-prefix, if ~/.xemacs cannot
Pema> be specified with it?
Allowing you to keep multiple installed package trees around. This is
really of most interest to developers with large changes in their
packages who also need to test against the stable versions of
packages. Most users or administrators should simply figure out the
incantation for --with-package-path that corresponds to site policy
for installing third-party software, save it in a script, and not need
to worry ever again.
In greater detail: we have been heading in the direction of a layout
(1) XEmacs version-specific material is installed under a single root
$prefix (by default /usr/local),
(2) the system package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages, under a single root
$package_prefix (by default /usr/local/lib/xemacs), and
(3) personal package hierarchies are installed in xemacs-packages,
mule-packages, and site-packages under a single root (pretty much
hard-coded to ~/.xemacs, although you can use --user-init-directory to
change it at run-time).
So there's actually little point to allowing the user to specify a
single location for early (ie, personal) packages.
It seems a little silly to have the extra layer of subdirectories
under ~/.xemacs since most users will not have personal packages
containing non-ASCII characters while using a no-Mule XEmacs. I guess
Ben decided to code --with-package-prefix that way. I personally
do use the extra layer of subdirectories, and it simplifies the
load-path-generating code slightly, but I can't really say Ben's way
is *wrong*. (That's why I say there's no point in arguing the
defaults, in the absence of other improvements.)
There's also some disagreement on (1) how much we should "encourage"
the simple architecture (which currently violates the FHS for system
installs because we don't use $prefix/share), and (2) whether (and how
much) we should "encourage" a particular relationship of $prefix and
$package_prefix (specifically package_prefix=$prefix/lib/xemacs,
although in practice the proponent of that restriction effectively
uses package_prefix=$prefix in his personal installation).
 The division into xemacs-packages, mule-packages, and
site-packages is mostly for administrative convenience.
(mule-packages does have the role of allowing literal non-ASCII
characters, which no-Mule XEmacs can't read correctly and can even
cause a syntax error, but that restriction will also go away in the
next release.) There's no reason why an installation can't put
everything into xemacs-packages.
School of Systems and Information Engineering 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.