Re: [comp.emacs.xemacs] AUCTeX 11.84 released

Olivier Galibert <galibert(a)pobox.com&gt; writes: Uh, the copyright holder of AUCTeX is the FSF. There is little sense in using different strategies for ensuring GPL compliance for packages from the same copyright holder. I had previously suggested that the XEmacs team stop distributing a badly configured, deficient and outdated version of AUCTeX since this would make it easier for users to install a proper uptodate and working package from upstream, in addition to allowing GNU/Linux distributors of offering drop-in RPM and .deb files for _current_ versions of AUCTeX that would not have potential conflicts with the outdated Sumo variant of AUCTeX. However, the reaction to _that_ suggestion was that Stephen was of the opinion that most people would rather have an outdated, deficient version of AUCTeX than a clean slate from which they can just use what upstream provides. Basically I have two issues at the current point of time: 1) the AUCTeX version XEmacs decides to distribute is basically unmaintained, outdated and deficient. It gives upstream a bad reputation. 2) independent from that, and not specific to AUCTeX, I don't see that the package system XEmacs employs, in connection with what the XEmacs team considers constituting a package facilitates meeting the requirements of the GPL. Those are different issues. Solutions for 1) would involve 1a) make a proper package and distribute that (required work) 1b) distribute the proper package made by upstream (requires policy change) 1c) stop distributing AUCTeX while upstream does a better job (requires dealing with surprised users that don't use the XEmacs package system for keeping their XEmacs in shape, but rather replace all of sumo manually or with OS packages). 1d) LALALALALALALA, I DON'T HEAR YOU. As for 2), I'd suggest the following solutions: 2a) collect what is necessary in order to turn a binary package back into a working source package such that one can hope to drop it into an XEmacs build tree from a later date without package-specific files of its own, and hope to have it still build. Put this metadata into a reasonable place in the binary package. This increases the distributed package size slightly. 2b) just package this metadata into a separately distributed "build pack" for the package, or pack it together with all the source data in source tree arrangement. This increases the required server space considerably. 2c) whenever new packages get generated, pack the whole source tree corresponding to all packages and offer a package of that. 2d) describe the layout and build process of XEmacs binary packages in your view and your terms to copyright-clerk(a)fsf.org and wait what he recommends. 2e) ask me to ask him. It is an option I don't particularly like since I get enough abuse from the list as it stands. 2f) LALALALALALALA, I DON'T HEAR YOU. At the moment, it looks like 1d+2f are the option of choice for dealing with the problems, respectively, except that it is "I DON'T HEAR YOU, AND YOU ARE UGLY TO BOOT". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta