xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff)

[Ville Skyttä]

For those who haven't noticed, FE6 will ship XEmacs 21.5.x.
Additionally, I've recently realized that stuff in the xemacs-sumo
package is not really built from sources; only patched *.el have been
recompiled to *.elc, and the majority of upstream byte-compiled *.elc
are shipped as-is.  It's time for that to change, but it requires some
packaging changes too.  Warning: longish mail containing thinking aloud
and some instructions follows.  Not that it would really necessarily
deserve this long an explanation, but I just wanted this dump somewhere
out for reference.  (Maintainers of XEmacs related packages in FE also
Bcc'd in case they're not on the list.)

Currently, the few bits in xemacs-sumo that are actually rebuilt are
done so using the xemacs-nox package, without xemacs-nox having any
dependencies to xemacs-sumo in order to avoid a build dependency loop,
ie. a bootstrap problem.  However, that won't work when everything is
built from sources; some bits require a XEmacs that has X support to
build.  The main xemacs package currently has a dependency on
xemacs-sumo, that has to go too in order to avoid just moving the build
dep loop elsewhere.  So, I'm planning to reorganize things for FE6, but
exactly how to do it is still an open issue.

First, one plan is to split xemacs-sumo to two.  The smaller bit,
xemacs-packages-base, will contain packages that upstream considers the
minimal set: xemacs-base, efs, and mule-base.  This will be compiled
with xemacs-nox, and will be enough for people who choose to manage rest
of the upstream lisp packages using XEmacs's built in tools instead of
installing them from rpms.  The second part, xemacs-packages, will
contain practically rest of the current sumo and it will be compiled
with the main X-enabled xemacs.  These packages will not be called
"sumo" because they no longer quite represent what upstream calls sumo
either.  Backwards compat Provides/Obsoletes will be there, naturally.

Second part of the above plan is that the main xemacs package will no
longer have a dependency to xemacs-packages (ex-sumo, due to the build
dep loop above); it will have a dependency on xemacs-packages-base only.

So this is what it would look like (versions dropped for brevity):

xemacs: dep on xemacs-common, xemacs-packages-base, provides xemacs(bin)
xemacs-nox: depends on xemacs-common, provides xemacs(bin)
xemacs-common: no xemacs* deps
xemacs-packages-base: depends on xemacs-common
xemacs-packages: depends on xemacs-packages-base

The most significant change for users and packagers is that the main
xemacs package will no longer pull in all the xemacs lisp packages
formerly in Sumos.  Users who upgrade will get the same functionality,
but ones who install from scratch, will need to install xemacs-packages
in addition to xemacs to get the same lisp bundle as was earlier pulled
in by just xemacs.  But packagers should be aware of the changes, too.

I looked into current FE packages that have some XEmacs things, and it
looks like some work is required in all of them, some less, some more.
This is "IMO", not a policy, and not all findings are related to the
xemacs-sumo split, and some are applicable to GNU Emacs lisp packaging
too.  Here's a rough checklist for runtime dependencies:

1) Makes sense with full featured xemacs only, not -nox ->
   Requires: xemacs.  Additionally, if it requires something from 
   xemacs-packages -> Requires: xemacs-packages - as said above, that's
   no longer pulled in by the main xemacs package.

2) Makes sense both with full featured and -nox -> Requires:
   xemacs(bin).  Additionally, if it requires something from
   xemacs-packages -> Requires: xemacs-packages.  If not, but requires
   something from xemacs-packages-base -> Requires:
   xemacs-packages-base (because -nox does not and can't have a dep on
   xemacs-packages-base - that'd result in a build dep loop).

3) Ships *.elc (IMO everything that is not a simple init-like file
   dropped to site-start.d should be byte-compiled into *.elc during 
   build!) -> Requires: $xemacs >= $version (versioned!), where $xemacs
   is xemacs or xemacs(bin) determined by 1) and 2) above, and $version
   is the version of xemacs (or -nox, see build stuff below) that was
   used to compile the *.elc.  An example how to take care of the
   version part will be included in the upcoming xemacs-packages and
   xemacs-packages-base packages.  The version is important because
   there are no backward compatibility guarantees for *.elc.

One specific example is that Requires: xemacs-common is most likely a
packaging bug and should be changed to (a versioned) Requires: xemacs or
Requires: xemacs(bin) as appropriate.

Build time dependencies:

a) Can be built with xemacs-nox -> BuildRequires: xemacs-nox.  If also
   requires something from xemacs-packages to build -> BuildRequires:
   xemacs-packages.  If not, but requires something from 
   xemacs-packages-base to build -> BuildRequires: xemacs-packages-base.

b) Can not be built with xemacs-nox, requires full featured xemacs to 
   build -> BuildRequires: xemacs.  If additionally requires something
   from xemacs-packages to build -> BuildRequires: xemacs-packages.

For simplicity, b) could be applied to all xemacs lisp packages, but
deciding between a) or b) as applicable allows for a more
optimized/minimized set of build dependencies.

Open issues:

- Is xemacs(bin) is a good name for the Provides provided by xemacs and
xemacs-nox?  One alternative would be to rename the current main package
to let's say xemacs-x, leave xemacs-nox as is, and have xemacs-x and
xemacs-nox simply provide "xemacs" instead.  This would however be
slightly less backwards compatible in the "install from scratch" case
than the xemacs(bin) approach.

- Would it be better to fold all the sumo/lisp package things back to
the main xemacs source rpm?  This would allow making some things a fair
bit simpler, and would also make it possible to drop xemacs-nox
altogether; as long as emacs-nox exists, I'm not sure if anyone really
needs it.  The drawbacks of the bundling would be kind of gratuitously
arch-specific lisp subpackages (OTOH in rpm arch only, the content would
continue to be arch independent) and that updates for the whole shebang
would need to be shipped all at once.

Hm, strange.  Having written the last paragraph, I'm starting to lean
towards it ;) (including dropping xemacs-nox).  Comments welcome, either
on or off list - I'd like to have a firm plan how to proceed at end of
this week.