>>>> "ms" == Michael Sperber
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
ms> ... which is whether a vanilla-configured XEmacs *without* any
ms> special indication where the packages should snarf them under
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.