[I'm redirecting this response back to xemacs-beta] sb> Right. Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt; writes: That's not the way I'm planning on doing it. For the first implementation I planned on being very simple minded about it. We know the list of files to install by doing and saving a `tar tf' of the package we're installing. This MANIFEST needs to be saved somewhere after installation. We could save either the list of files or a machine-generated deletion shell script. The former would be more flexible. As good a place as any to save these would be in etc/MANIFEST/, with the individual file names being derived from the package name. That way we can `locate-data-file' and friends to access them from Lisp. If we store it as the package name + package version number, we have the ability to detect the situation where the installed Lisp package doesn't match the version in the database. I am assuming that this file *does not* come in the package tarball. It is generated by the same procedure that installs it. This won't completely work for de-installation because we need things to work somewhat even if the MANIFEST files get misplaced[1]. We also need to deal with files that may not be present at installation (*~ backup files come to mind). A brute force thing to do is to `/bin/rm -rf etc/${PACKAGE} lisp/${PACKAGE}' in addition to removing all the files from a previously installed version. This will also catch the case where a file has been removed from a package and the installed MANIFEST file is missing. If the MANIFEST generation/previous version deletion is done in the lib-src shell scripts it will be transparent to package-get *and* still allow for manual package installation from the command line so long as the scripts are used. Footnotes: [1] Do we really? It will certainly help testers who already have a populated Lisp package hierarchy and bozos like me who will forget and install things by manual untar in the appropriate directory.