Dramatis personae: mb> I strongly resist making changes to directory structure, mb> especially this late in the release cycle. (wait, SJT is the mb> release manager! Have to stop speaking that way!) Why? You're a member of the community, a tester, a developer, and a Board member. Release Manager trumps all of those, by definition, but if your opinion is strongly expressed I will certainly take notice. OK, Martin's right. I really really would like to do it Michael's way, but I don't trust CVS to DTRT with migrating files across directory structure---twice, if for some reason we decided to revert. (Remember, most of our active testers now do CVS updates AFAICT. This means bug reports from those who don't have the -dP flags set just right. A lot of them may have joined since the Great Package Exodus debacle---they may not. And those who don't do CVS are just as bad, they probably will just untar over the old hierarchy.) I can't resist some technical discussion, though: SJT> This change can be interpreted as making the treatment of SJT> Mule consistent between core and packages. Martin> But it's what the packages do that's broken. Users should Martin> think of a single set of packages, some of which have Martin> attributes, such as requiring mule, not two sets of Martin> packages. The problem is that accidentally loading a package requiring Mule is not something that a no-mule XEmacs can safely deal with. Go ahead, Martin, symlink lisp/great-new-feature.el -> /vmunix, add it to loadup.el, and see what `make all' does with that. Mule Lisp is _worse_: it looks like Emacs Lisp but isn't. It does not follow the same lexical rules at the level of stream reading (or writing, but we can live with that). MS> Well sure, but there we are now: Currently, Mule and no-Mule MS> are completely different things, and the package system is MS> broken. Once these two things are fixed (provided they ever MS> will), then we can---and will---unify these things. I'm only MS> suggesting that we reflect the current situation accurately, MS> and solve the technical problem we're having right now. mb> I'm not sure I understand what the technical problem is right mb> now. I assume we're still trying to solve the excessive stats mb> problem. Not really. I think that, for reducing stats, your technical suggestion (if mule, adding lisp/mule as another hierarchy of depth 0) probably works as well as Michael's for as long as we need it to. The technical problem that I'm interested in is making the _minimum_ number of changes to the path search code when we get rid of the bogus mule/not mule distinction. Michael's strategy shows some promise here, since we would simply merge the roots of trees of homogeneous depth. In your strategy, merging the packages is easy, but the risky work of merging the heterogenous core hierarchies (which overlap in your model!) remains. Michael's strategy also trivially solves the technical problem of dealing with a mule hierarchy with autoloads: do it just like lisp. I _think_ yours does, too, but it takes more thought. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."