Hello,
it's not the first time this topic has been discussed, but a recent
thread on comp.emacs.xemacs and its solution have made it more
pressing.
The situation at the moment is that Reiner has, after a user had
problems in getting a working AUCTeX on XEmacs, used the Makefile
target in our distribution to create such a package and put it online,
which the user (who did not have recourse to the required build tools)
could then just install.
I think it is pointless to force users to recompile. XEmacs packaging
policies mean that Uwe, the current AUCTeX package maintainer,
basically has to take a working package, unpack it, rearrange the
results in a manner that would match a typical source in the XEmacs
package source tree, check it in, write and maintain metadata, just in
order to arrive at the same package he started with, modulo mistakes
and different versioning. Then _another_ person is responsible for
the actual build and distribution.
Even if Uwe had perfectly much time and energy available for that job
(which he hasn't), it is not likely that this way of processing will
cure more problems than it causes. And the persons responsible for
the problems introduced in this process are not core AUCTeX
developers.
I think that in interest of coherence and of the users, we should just
bite the bullet and put the XEmacs package up for download ourselves,
right from the official AUCTeX download site instead of hidden away on
the private ftp space of a developer.
The version numbers should make telling apart our XEmacs packages from
the "official" ones easy enough. We'll have to figure out what to
write in our installation instructions and release documents, though.
It may be reasonable to omit everything pertaining to building an
XEmacs package from the user-accessible documentation in the tarball,
and instead make that just part of the CVS archive.
The question is what to do with the version in the XEmacs package tree
and available from its servers.
There are three possibilities:
a) business as usual. Updates will occur when somebody has time and
is willing to do them. They involve quite a bit of manual error-prone
work.
b) stop updating AUCTeX altogether but keep it on the package servers.
c) remove it from the package servers.
It is actually the call of the XEmacs packagers how they want to deal
with that issue. But I don't think it serves AUCTeX development if we
try feeling responsible for the results of a process that is quite
outside the hands of the core developers. And I don't feel Uwe should
be held responsible for problems that should not be there in the first
place.
Distributing a standard package ourselves would solve most of those
problems, and maybe we can even cater for the metadata that would be
required so that our download directory can get listed in the package
download areas in XEmacs' package manager.
We do have to come up with a good idea about things like AUCTeX RPMs
for XEmacs, though. We can't have them install into the standard sumo
tree because of file conflicts with their AUCTeX versions, and they
are not really appropriate for site-packages, either, because that is
for local stuff.
Is there a package tree intended for OS distributors? Search order
with higher priority than the standard tree (and not conflicting with
it), but below site-packages tree? Something like dist-packages?
If not, we'll probably have to go with the site-packages tree.
Anyway, even while just putting this into RELEASE and README as a
separate "is available" item, we should in the long run also adapt the
documentation accordingly.
I don't think "how to build an XEmacs package" in its current
invocation should be part of the user documentation, as it requires
CVS access and does not work right off the tarball at the moment.
Maybe it should, but it seems more important right now to tell people
what to do once they _have_ gotten hold of a binary package, rather
than tell them how they could generate one themselves.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum