Re: [FAILED] XEmacs 21.2.15
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org:
SL Baur <steve(a)xemacs.org> writes:
> I don't think so. This is a dump-time mis-interaction. The rules
> were very carefully laid out to provide maximum flexibility in the
> search order.
Would there be a way to guard better against that. When 21.2 is
released surely there are bound to be users upgrading the packages in
the same way?
Actually, 21.1 isn't incompatible in this fashion, Stephen and
the others were using pre-21.0-final mule-base packages -- if you live
on the bleeding edge and do not keep sufficiently up-to-date expect to
get cut once in awhile. There's no reasonable precaution we can make
and we cannot avoid changing things in test releases when they need to
be changed.
We probably ought to pitch everything unnecessary to building right
now to avoid this sort of thing in the future. Superfluous undumped
stuffs like apropos.el, cus-edit.el etc. shouldn't be in the core. I
have hesitated because of past squeals of pain, but I think the time
is probably right, now. The XEmacs core should only contain the
minimum files necessary for making an xemacs binary *and* to provide
for minimal vi-equivalent editing functionality. Everything else
should be loadable at run-time, that way it isn't bloat.
I am looking at getting rid of the Mule language-specific dump and
making language support autoloaded. I believe this is do-able, but I
need to do some experimentation to be sure.
--
I protest the NATO war in Yugoslavia.
I protest the use of depleted uranium weapons against any human being.