Michael> For XEmacs, what's needed is something which works at the Michael> package level in a quite different way. Karl> Tell me if I'm way off base. I feel like I barely know what I'm Karl> talking about. Not at all. Karl> It would have to run an `install-xemacs-package' utility that Karl> updated that database. I think that the question of whether or not to have a database with package information around should be orthogonal to the design of the package layout itself. I think the package layout should provide all relevant information purely by and of itself in a manner as non-redundant as possible. The package system should be able to function without *any* auxiliary databases. Once the package information is sufficiently reified within XEmacs, it should be very easy to add optional and completely transparent database support to speed up access. I personally have been hurt time and again by software which keeps redudandant databases of auxiliary files, which is why I'm (and my users) are very willing to pay a price in startup speed for guaranteed system consistency. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla