Re: with-package-prefix

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 where (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[1], 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). Footnotes: [1] 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.