At 05:07 PM 5/6/98 +0200, Michael Sperber [Mr. Preprocessor] wrote: My version of package-get-base specifies fsf-compat, mail-lib and edit-utils as single file packages, this is the crux of my problem, extraction of single file packages doesn't appear to work (this is known?) but also shouldn't these be regular packages? andy

ms> The package-admin-add-...-package functions do this to ms> determine where to install: ms> (setq pkg-dir (car (last late-packages))) ms> So you should look at `late-packages'. I don't really feel ms> comfortable with this, but there's generally not a good ms> solution to the problem that packages are searched along a ms> *path* but have to be installed into a *directory*. boku> Here's a guess at the rationale for that choice. If the boku> sysadmin has modified a standard package, then they install boku> that up front in the late-packages path and the automated boku> update procedures thus don't override the localized package boku> with the latest released version. Close enough? This turns out not to work as I thought because of the recursion into directories that the sysadmin knows are irrelevant (but XEmacs does not). Here's my late-packages: ("/playpen/gnu/xemacs/packages/" "/playpen/gnu/xemacs/packages/TarFiles/" "/playpen/gnu/xemacs/packages/sources/") Since /playpen/gnu/xemacs/packages/ is fully populated, this means if I use the automated mechanism to upgrade, the updated packages will disappear into a black hole as far as XEmacs is concerned. There is no excuse to remove those bogus trailing directories, since "an empty package directory is a perfectly valid package directory". I don't see how the administrative strategy described above can be implemented unless administrators are strictly prohibited from creating subdirectories of the package root that do not contain usable package data. Doing `(setq pkg-dir (car late-packages))' is clearly the wrong thing from that standpoint. OK, I move those directories to /playpen/gnu/xemacs/TarFiles/packages/ and /playpen/gnu/xemacs/sources/packages/, respectively. (Ugh, but if you insist....) If you're going to force me to do that, you may as well go all the way to mandating The One True Package Hierarchy Structure; it will make life a lot simpler. This makes the whole idea of recursive search irrelevant, at first glance, anyway.