The following is unofficial, but it works for me :-) Geoffrey> Okay, I updated the package index, and then ran list and Geoffrey> install. However, this does not change the fact that Geoffrey> XEmacs' package for pcl-cvs is 4 months out of date. Geoffrey> My question remains: What is the expected modus operandi Geoffrey> here for coping with the time lag between XEmacs Geoffrey> packages as compared to the thing they are packages of? The "expected" modus operandi is to wait for the package version ;-) That's what most users will do for most packages. In the long run, of course we hope that the advantages of this form of distribution are so obvious that GNU adopts it and all package maintainers release their libraries with the package as the preferred distribution medium, so there will be no lag. If you need to be on the bleeding edge, for most packages it works like this: 0) (Done once, you don't need to do it again, unless you decide to revert to the XEmacs distributed version.) Check the package out from CVS at cvs.xemacs.org. You also need to check out the top level helper files (the XEmacs.Rules GNU Make include file, the package-compile.el byte-compile driver, etc). The source tree and the library tree _must_ be separate as far as I know. You'll probably have to move the directory structure around a bit because of the way the XEmacs modules are organized. See http://{cvs,www}.xemacs.org for the specific checkout procedure and list of modules. IIRC, it won't explain the tree organization (packages live two levels down from XEmacs.Rules and co is the main consideration). 1) Tweak make variables like STAGING directory appropriately for your local environment. (Also done once.) 2) Download the package from the upstream source. 3) Untar in the package's directory in the local CVS tree (making sure to preserve the XEmacs Makefile; IIRC, all other XEmacs-specific files are generated by the Makefile). 4) `make' the appropriate target (probably binkit). 5) Point package-ui at your STAGING area, and install the binary package into your library tree. Yes, it really normally is that easy. Caveats: Some packages depend on other packages to build correctly. These dependencies are specified in the database. You'll have to get them all and put the source into the local CVS tree mirror, but you only need to actually build the one you're interested in. If these dependencies change, they can be hard to track down. One hopes the upstream source will have a NEWS or ChangeLog entry. The actual targets for making and installation are listed in variables in Makefile. If these change, you'll have to update them. Some packages need to have rude things done to the Lisp environment or they won't byte-compile, or worse they byte-compile incorrectly. This is mostly automated by the package-compile.el, but it's a potential gotcha (it got one of the core XEmacs maintainers recently :-). You would like to update the package version. Unfortunately, as yet there is no set convention for "private" versions, and the package system doesn't know about upstream versions, so it won't be able to handle upgrading your private package when the new version does arrive at xemacs.org. Of course, if you are _permanently_ on the bleeding edge, this won't matter, except that your package database will always be incorrect with respect to that package. But if you prefer to revert to the -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."