Re: [Bug: 21.4.18] site-lisp not in load-path

ms> Could you summarize what problem you're trying to solve here? ms> I'm a little lost. There are three problems, actually. One is the path inversion between source, especially "large" 3rd party packages, and installed hierarchies. In source the structure is quite often xemacs-packages/$PKG/lisp/*.el, while installed it must be xemacs-packages/lisp/$PKG/*.el. This means that we can't run in place in the package tree. Transitioning to $PKG/lisp in the installed tree is a problem requiring some effort, I believe, because a number of tools know about the structure of the installed tree, and we'd need to check on which ones care about that. A separate hierarchy offers a place to experiment with and make the transition without screwing up old packages. The second problem is "large complex packages". I especially have in mind JDEE and Emacspeak, whose upstream maintainers won't touch the XEmacs packaging because the installed hierarchy is too different from their idiosyncratic ways of doing things. (42 JDE_DATA_GOES_HERE Make variables, anyone?) Perhaps AUCTeX, too, but at least as of early 11.x it wasn't that big a deal to force AUCTeX into an XEmacs installation. Those packages already have their own idiosyncratic "find my info, find my data" kinds of functions, so why not let them do it their own way? The "opaque packages" proposes to enable just that by getting the minimum amount of information needed, all of it hand-coded by upstream (at least in principle), in auto-autoloads. To complete the transition of making the source and installed structures the same, we'd provide standard data-finder functions (although mostly we have such functionality already, I suppose they presume the existing structure, and also as far as I know do not provide hooks for packages that have their own ideas about how to do things) and of course XEmacs-maintained packages would have a nice regular structure conforming to them. The third problem is that the existing hierarchies have no good place for executables and modules. Of course that's not quite right, the real problem is that since they're architecture-dependent, we can't distribute pre-built packages anyway. Still, lib-src and etc are strange places to put scripts and the like; we'd like to have bin and lib directories (and FHS fans probably want share :-). -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.