Jan> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Jan> It is/was in 21.1. Is no more in 21.2. Jan> Huh? Why? There are *two* now under ~/.xemacs: xemacs-packages and mule-packages. Jan> Please define 'sloppy'. There's no clear concept of where the package index is really supposed to go. `package-get-locate-index-file' calls `locate-data-file', but the location where the package index is *stored* is not inferred from `data-directory-list' at all. Moreover, `package-get-locate-index-file', as a last resort, just returns `package-get-base-filename' without checking for its existence. Jan> Please define broken? It al does what it is supposed to (modulo "~") Jan> 1. Get the package index from the best location possible. Jan> 2. Get the file locally using the standard XEmacs data file Jan> algorithms. Jan> 3. If the two don't match offer to update the local file if we can Jan> write to it. This is all cool. Jan> 4. If we cannot write to it, offer to write it to a location where the Jan> user is likely to be able to write and where XEmacs will find it Jan> again (i.e. the etc directory of the users package hierarchy). But there's a strange mixture of genericity (`locate-data-file') and hard-wired path construction (like (expand-file-name "etc/" package-get-user-package-location) ) going on. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla