Steve and I have been discussing a general overhaul of the package system which is necessary to solve some of the problems that have shown up over the past. Examples are Didier's gripes, Valdis's comments, the ps-print mess, different tracks of Gnus etc. etc. etc. which the current system does not handle gracefully. Here's the rough draft for a new package system design. I tried hard to address all reasonable issues posted over the past. I'd appreciate if people, before yelling at me because of problem X I've forgotten, would first ask me how to solve problem X in this framework. Chances are fair that I'll have an answer. Let me know what you think. This is from scratch. Forget the current layout, forget about the current handling of auto-autoloads etc. etc. etc. A package is a collection of files constituting an extension to XEmacs that may be optionally installed or uninstalled as a unit. A package has the following properties: - a name (a symbol) - a description - a version (a string "<major>.<minor>") - an author version (a string, free format) - a maintainer (a string) - a predicate indicating whether it can run in a given incarnation of Emacs - a list of package specifications (see below) which must be satisfied for the package to be able to compile - a list of package specifications (see below) which must be satisfied for the package to run (I did not worry about things like checksums, as I'm not an expert on that stuff, but they are supposed to be in there as well.) The following constraint must hold: Two different author versions of a package must have different versions as well. A package is distributed as a directory hierarchy; all files belonging to one package live under that directory, no other files do. The name of the directory uniquely identifies the name of the package as well as its version. Apart from that property, the name of the direcory is completely free-format. The layout of a package is essentially as before. The subdirectory names recognized by XEmacs are the following: etc info lib-src lisp man Moreover, it contains a file specifying the above attributes. An extension of the old package-info would do nicely. A package drops into a *package hierarchy* which is just a directory containing package directories. A package hierarchy has the following properties: - a predicate indicating whether its packages can run in a given incarnation of Emacs Installation happens simply via dropping a package into a package hierarchy, uninstallation happens via removing its directory. There are no associated database files which must be held consistent. via *package specifications*. Here is the syntax for package specifications: <package-specification> -> <package-name> | (<package-name> <package-property>?) <package-property> -> (version <version>) | (at-least-version <version>) | (at-most-version <version>) | (and <package-property>*) | (or <package-property>*) | (not <package-property>) <version> -> <string-literal> <package-name> -> <symbol> The semantics is mostly obvious, hopefully. Do note that the mantissa of version numbers is interpreted in a way different from that of floating point numbers, but rather in the way common in the software world. I.e., "1.10" denotes a later version than "1.2". Moreover, if several packages match a package specification, the specification identifies the one with the latest version. Examples for package specifications: gnus (gnus (at-least-version "1.12")) (efs (and (at-least-version "1.12") (at-most-version "1.15))) (gnus (not (version "0.84"))) API: These are all necessarily macros because they deal with package specifications. However, they transliterate trivially into function calls such that their definitions will not have to change ever. Maybe even the underlying functional interface can be exposed. (package-present-p <package-specification>) This tests if a package matching the specification exists. It has no side effects. (use-package <package-specification>) This indicates a preference for a package matching the specification to XEmacs. This means that, in the future, no other packages with the same name may be used in the running XEmacs. It also has the side-effect of making the package's autoloads available. (require-package-feature <symbol> <package-specification>) This is like `require', except that it doesn't require quoting and is relative to a package specification where the feature must reside. (provide-package-feature <symbol> <package-name>) Like `provide', only relative to a given package. (locate-package-directory <exp> <package-specification>) (locate-package-library <exp> <package-specification> &optional ...) (find-package-library <exp> <package-specification> &optional ...) (load-package-library <exp> <package-specification>) (locate-package-data-directory <package-specification>) (locate-package-data-file <exp> <package-specification>) (locate-package-executable-directory <package-specification>) (locate-package-executable <exp> <package-specification>) (locate-package-info-directory <package-specification>) (locate-package-info-file <exp> <package-specification>) These are all like the equivalent existing functions, except that they are relative to a given package specification. The existing functions continue to exist, but change their behavior: Nothing related to packages shows up in the relevant ...-path and ...-directory-list variables. (I.e., package lisp subdirectories do not end up in `load-path.) However, the relevant functions which used to search in them still go through the package directories as a last resort.