Future AUCTeX distribution

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