Re: Package system improvements!?

Mats Lidell writes: What do you mean by "supported"? In some sense it's "oversupported". At least *seven* switches in configure (--with-{user,early}-packages, --with-{system,late}-packages, --with-{legacy,last}-packages, and --package-path) and an environment variable (EMACSPACKAGEPATH) can specify where XEmacs should expect to find packages at startup. Besides that, there is an additional mechanism to locate packages for run-in-place instances of XEmacs. *If* those configure switches are specified in configure, it seems reasonable to suppose that the user wants packages installed there. OTOH, a lot of users will just default the choice, and we'll want to install into $prefix/share/xemacs or similar. Some of those users will have diligently kept their package tree up to date, and not want us overwriting anything. Others will have a sumo from 2003, and will want the most recent version. But some users have more or less good reasons for not using the default. Eg, Debian puts our packages in /usr/share/xemacs21. Then we probably don't want to overwrite Debian packaged stuff, but we should warn the user. The package system has logic to *find* them. It's configure that would need to decide where to *put* them. That's plausible if we're going to bootstrap from a few packages, and then install the collection of current versions (especially if the process will be interactive). Then we can just delete the bootstrap packages, and nobody will notice. But the same system should be able to handle installation of a sumo. Then we don't want to delete those packages. But it would be bad if there were two whole hierarchies. The whole point of the package system is to share a single installation, and there are practical issues with shadows, too. And of course, the "usual place" is where packages are most likely to exist, and that's where we should put any packages we're going to install. So, no, in practice I don't think we can have our cake and eat it too; we're going to have to ask the users what they want. The trick is to ask just enough, and not ask them to figure out what we can do automatically. But we could shadow them. That would not destroy their code, but it would be an unpleasant surprise. That's a convenient approach for us, but in practice users will be unhappy. Consider what happens when a user does `find-function' and decides to fix a problem in place. It's certain that a lot of changes inadvertantly end up in the package tree. Indeed. Just unpacking a sumo, well, I guess that's the user's problem. But where we provide a mechanism to do installation, one thing that we could do that's pretty simple is to add MD5s for all the source files in a package, and not overwrite a package where the checksum of any actual file is different from the manifest. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta