You say this: And then that: ... which I don't understand. 1/ Isn't this redundant ? 2/ What do you call an "Emacs incarnation" ? Is it the set of (GNU or X)-Emacs, (no)Mule and other compilation-time flags ? Is it a purely static thing, or does it include dynamic stuff, like "there's no reason to make package Foo available in the current XEmacs session, because it can only work under X and there're only tty frames right now" ? 3/ What do you call a package hierarchy exactly ? Can you have sub-hierarchies in there ? And what if a package has several of your predicates ? Where should it go ? To be more explicit, suppose package foo can't run under mule, package bar can only run under mule, and package baz can do both (it decides by himself). Where should they go ? Why not \usepackage{specification} ? :-) What happens if there's no match for this specification ? I understand that this is probably in case several packages provide the same feature at some point. But is it possible for a package to require another one ? Like, in gnus you would have (require-package w3 <spec). Which brings us to another point. Suppose I have a use-package for w3 and a certain spec, but gnus requires w3 with another spec. How will this be solved ? And a last question: what about the place of C modules in this package layout ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19