>>>> "sb" == SL Baur <steve(a)xemacs.org>
writes: 
    sb> Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in
    sb> xemacs-beta(a)xemacs.org:
> I do not understand why the SUMO tarball contains only
> packages. 
    sb> Because they are completely independent of XEmacs version and
    sb> I want the same Sumo to be usable with both 21.2 and 21.1 (and
    sb> InfoDock, for that matter).
Understood.  Taking that logic a little farther, though, the SUMO
fractures into packages again, as all of _them_ are independent of
each other.  SUMO is a convenience; if those who find it convenient
want it packaged with their source, so what?
> I think it was a mistake to separate the executable from the
> packages that way (SUMO lisp gets updated more frequently than
> the core tarball, but it's not that much more so, and it's
> error-prone). 
    sb> That's reflecting a problem in how I build Sumos.  I have
    sb> intended to keep Lisp packages more frequently updated, but
    sb> the expense of making new Sumos at the same time has been
    sb> overwhelming.
Is it really worth keeping SUMOs up-to-date?
If not, why not have a release schedule for SUMOs, once a month, say?
And rebuild KONNISHIKI (the SUMO-plus package which also contains the
kitchen current stable source release) at the same time?
> It would be better if SUMO tarballs contained all of XEmacs.
    sb> There currently isn't any way to build XEmacs completely from
    sb> scratch, even for me.  The Sumos aren't intended to support
    sb> being bytecompiled.
I still don't see what the harm would be in having a single tarball
(called whatever) containing both the source and a SUMO hierarchy as
it would be installed.
It should be trivial to build (if I'm wrong, I take that back).  Link
the SUMO hierarchy to some suitably named subdirectory mentioned
nowhere in any makefile except under the install target in the top
Makefile.  No?
We don't have a "bytecompile-packages" target in the source now; you'd
have to work at screwing things up, a lot harder than the (tar xvzf ...;
./configure; make; make install) process some folks want.
I have every reason to understand (and I agree with) your other goals;
but what's wrong with catering to people who have enough disk space
that they'd rather waste a few dozen MB rather than tell their fingers
NOT to go "(tar xvzf ...; ./configure; make; make install)"?
-- 
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 two straight lines for?  "Free software rules."