English

German

Japanese

America

Asia

Australia

Europe

Searching XEmacs Quick Links

About XEmacs

Getting XEmacs

Customizing XEmacs

Troubleshooting XEmacs

Developing XEmacs

SUMO integration

Stephen Turnbull <stephen@xemacs.org>
Volunteers eagerly sought!

We should reverse Steve Baur's decision to not distribute the SUMO Lisp in the main tarball. The packages are popular, but the typical user of the core tarball wants the kitchen sink.

This is not about reintegrating the packages into the core (a la the GNU mainline). Nobody strongly supports that.

We're talking about making the default distribution include the packages, or at least have an easily available all-in-one option. We don't really have that now, even with the SUMO: you have to fetch two tarballs, untar them in different places, make all these choices, ....

People who balk at a 35MB tarball will still have the disaggregated setup available.

Status

One proposal is as follows. Create the following series of tarballs for each release.

xemacs-21.4.0.tar.bz2

One-stop-shop. Unpack this under $srcdir, get all core source and data, .elc, .info, and the current SUMO tarball, in $srcdir/etc/. (Maybe $srcdir/xemacs-packages/, or $srcdir/sumo-data/. ./configure; make works as always. make install has a final step: if $srcdir/etc/xemacs-sumo.tar.bz2 exists, unpack it into $PACKAGEROOT.

Baroque, yes, but remember those vi-using sysadmins. They are used to being able to unpack into some random tmpdir. Anyway, SUMO unpacking needs to obey $datadir et al.

xemacs-21.4.0-src.tar.bz2

Core source and data, can generate -elc and -info. Connect cost optimization for the weakly-connected.

Maybe this tarball should include xemacs-pui-min.tar.bz2, and unpack it in $PACKAGEROOT? Alternatively, put them in $srcdir/xemacs-packages, to bootstrap list-packages. Then the install process automagically tries to invoke list-packages to install pui-min packages in $PACKAGEROOT, and only if that breaks use install?

xemacs-21.4.0-elc.tar.bz2

Compiled Lisp, build time optimization for the well-connected.

xemacs-21.4.0-info.tar.bz2

Generated Info, build time optimization for the well-connected.

xemacs-pui-min.tar.bz2

xemacs-base, efs: starter kit for list-packages. Tiny subset of SUMO, with same release schedule as SUMO. Also includes their dependencies, which I believe is dired for efs.

xemacs-sumo.tar.bz2 -> xemacs-sumo-2001-03-01.tar.bz2

Package SUMO, with release schedule separate from core. Steve Youngs thinks Mule should be excluded.

xemacs-sumo-mule.tar.bz2-> xemacs-sumo-mule-2001-03-01.tar.bz2

Package SUMO (Mule packages), with release schedule separate from core.

Alternatives

Steve Youngs suggests ``instead of integrating all of the packages back into the core, why not just xemacs-base, mule-base, efs and perhaps dired?''

Steve Turnbull replied ``I'd actually like to see more and more stuff pushed out of the core (but that is controversial). However, especially with well-maintained packages like dired and EFS, I think it makes a lot of sense to keep them separate. And surely the maintainer in question, Michael Sperber, favors packages!!''

A better alternative for putting more capability into the core might be Jan Vroonhof's proposal for a lightweight HTTP-based specialized bootstrap package-fetcher in the core. This would require that we set up some additional infrastructure on the web site. There is no way we can rely on having this ready by March 1, unfortunately.

Is this really necessary?

Steve Youngs reports

Having my hard drive go up in smoke has meant that I have had to re-install everything from scratch. When it came to XEmacs I did ...

[...]

Everything fine, no problems at all.

But it is a FAQ; obviously somebody is having problems. One important difference is that you knew what you wanted and had no trouble with the ./configure and M-x list-packages stages. Many people count on xemacs.org to provide a clear recommendation for a safe default install, and based on the FAQ count, we're falling down on that.

I know, anybody who can find the AnyKey should be able to install XEmacs with a little bit better docs. Of course they can. The point is that there are two kinds of users (newbies and busy admins) who could be better supported with some kind of all-in-one distro.

Open bugs

None. (Well, of course the current situation is a bug.)

Other open issues

None.

Discussion

We should reverse Steve Baur's decision to not distribute the SUMO Lisp in the main tarball. I don't know how much work this would involve. It could be as little as a change to INSTALL ("we don't support any means of installation that doesn't involve untarring the SUMO in $prefix/lib/xemacs; if you want to avoid that, read README.packages"). It could involve somehow including the SUMO in the core distribution. Or something in between (don't ask me what yet).

The packages are popular, but the typical user of the core tarball wants the kitchen sink. The package system is used to keep up-to-date on heavily used packages, or packages with important new features. People who want a subset typically are either capable implementing that themselves anyway, or should let their Linux distro deal with the issue, or can remove unwanted packages ex-post install via package-ui.

Closed bugs