reftex needs to be upgraded.

[Stephen J. Turnbull]

Hans de Graaff writes:

 > We can handle the versioning in the Gentoo ebuilds, so we do know which
 > packages are installed. We already do this now for the pre-compiled
 > packages as well. Unfortunately this information (against which version
 > of other packages this package should be compiled) is not available in
 > the package file itself.

True.  That kind of dependency is completely unsupported by the XEmacs
package system.  If you want to support them, you'll have to do it
yourself for the foreseeable future, because we don't know how to do
it even if we wanted to.  See below.

 > My understanding is that if I compile the package against xemacs 21.5
 > instead of xemacs 21.4, I get better results since I may not need to use
 > compatibility code in 21.4 that is supported in 21.5. Perhaps that
 > assumption is incorrect?

The only package where this matters a lot is APEL.  In most other
cases the compatibility code is a monkey-patch ported from 21.5 (or
more likely from GNU Emacs, and also sync'ed into 21.5).  You may have
some extra code, but it ends up doing the same thing.

 > The "recompiling" part is what makes this interesting. In CVS there is
 > an infrastructure to handle this using Makefiles, but that is not
 > available in the distributed packages. So I should just byte-compile all
 > the files again and hope that nothing special is done in these Makefiles
 > that I might be forgetting to apply?

What special treatment do you have in mind?  In practice, for separate
Lisp libraries (including collections like Gnus or Calc) there is
*one* compile option: to compile or not.

We do have an infrastructure in the CVS tree which ensures that all
code in the build environment comes from either the core of the
compiling XEmacs or the CVS tree.  That is the most important purpose
served by the package infrastructure.[1]  But that basically requires having
the whole source tree in place.  As a package distributor, you should
consider the CVS tree a monolithic source, as we do.  Then break out
the separate packages that you want to distribute, as we do.

As a user, you just byte-compile the files that you have.

 > > What exactly do you want to "get working"?  Compiling in the user's
 > > environment is trivial, but versioning any compiled Elisp is really,
 > > really hard; we've never been able to get a complete handle on
 > > dependencies (darn autoloads ...).
 > 
 > Compiling in the user's environment is nice to have since it keeps in
 > line with Gentoo's philosophy.

Then give the users a snapshot of the CVS source tree.  That's
effectively what GNU Emacs does, but it's still somewhat smaller than
ours.

 > The ability to patch the elisp code is also very useful since that
 > enables fix problems (security issues come to mind) that might crop
 > up without having to wait for official packages.

Yeah, well, you can't have both.  By the nature of things Lispish such
interim fixes can have a significant effect on the user's environment,
and you no longer can be confident of what "version" that environment
is when you compile new packages in it.

Not to mention that Emacs Lisp is worse than GNOME for having
interlocking dependencies.  And really, you need to track dependencies
at the defun level, not at the library, let along the package level as
the distros do.  On the one hand, if you have a bug in a function and
you fix it, all you have to do is monkey-patch the running Emacs by
executing the fixed defun or a defadvice.  (This is effectively what
APEL is, an extensive collection of monkey patches.)  On the other, if
you fix a bug in a macro or defsubst, then you must recompile every
function that invokes that code---recursively (macros often invoke
other macros).

I'm not saying what you want to do is stupid; just that the design of
Emacs Lisp makes it a lot more complicated than it is for sensible
programming systems (eg, Brainf*ck or Intercal).

Footnotes: 
[1]  Much of the code, on the other hand, is devoted to just moving
the enormous variety of source layouts into our uniform installed
layout.