Re: find-paths.el and run-in-place

ms> before you make sweeping judgements like this, it would be ms> nice if you could calm down and review the issue at hand ... I have. Carefully. But I don't have access to your systematic thoughts, as there is no design document. My semi-systematic thinking follows. ms> ... which is whether a vanilla-configured XEmacs *without* any ms> special indication where the packages should snarf them under ms> /usr/local. What I expected is that XEmacs would look for a "package root" (ie, a directory containing one or more *-packages subdirectories, and not necessarily the same as an "XEmacs root") named $datadir/xemacs. That's the historical location for XEmacs-related stuff not XEmacs-version- or architecture-specific. In a vanilla-configured XEmacs, that is /usr/local/lib/xemacs. And until a couple of weeks ago, that is what happened. Purely by chance, yes. But it seemed quite logical when it did happen. Of course I'm presuming --with-prefix=yes (which is vanilla==default). ms> There is no correct answer to this question, as we've had bug ms> reports from environments where this is precisely the *wrong* ms> thing to do. Can you point me to some of these bug reports? And if it is not obvious from the reports themselves, explain why the preferred solution in those environments is not --with-prefix=no? ms> I think it's it's entirely reasonable to expect an explicit ms> hint on where the packages are, that is, either via the ms> --package-path configure option or via the EMACSPACKAGEPATH ms> environment variable. I think it is entirely reasonable for testers to expect the hint to default to $datadir/xemacs under ./configure;make;src/xemacs. ms> The criterion [for an XEmacs root] changed at your (Stephen's, ms> that is) suggestion, and justly so. I didn't realize that that meant that packages would then be considered squatters, with no home of their own. I think that is very bad if XEmacs is configured --with-prefix=yes. I suspect you'd like to deprecate that practice, but in that configuration, I think XEmacs _should_ make an assumption about where it can find the packages. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.