Re: Fwd: sign off on XEmacs 21.5

David Kastrup writes: I'm sorry, David, but you are wrong on this. You could argue "practicality beats purity", ie, the benefits of working outside the package system outweigh the inconsistency. (That argument now fails to the reality that we will shortly have a current AUCTeX built inside the XEmacs package infrastructure.) But to argue that it does not matter at all how the package is built is completely unsupportable. All distributions insist on building their distributed packages themselves, usually with a specific build system to ensure that they conform to certain practices. (The only exception I know of is the GNU Project itself, whose distribution is indeed just a collection of tarballs offered by individual GNU projects.) When the practices change, the build system is changed, not the package sources. Then all packages are automatically rebuilt to the new standard. Of course in practice it is rarely that smooth, but that is the goal, and most packages do upgrade successfully. But in the case of the so-called "XEmacs package" provided by the AUCTeX project, that will fail *by design*, since by design your build process ignores the XEmacs package infrastructure. Of course you do. You're basically saying that in comparison to Emacs, a comparison you've made many times. Well, that comparison is inherently unfair. And at this point, the "external package" issue is pretty much moot because Uwe and Mats have succeeded in building an AUCTeX 11.8x package with the XEmacs package infrastructure. Which is itself strong evidence of support. I beg to differ. All they need to do is provide an upstream-based package separately and a post-install hook to their XEmacs SUMO package or XEmacs virtual package that recommends installing it, and does so by default. They may prefer not to do that for some reason, but it is most certainly feasible and not technically difficult. ***** Overall, I can't judge what is best for AUCTeX, since I'm not involved in the project. But the reasons you're presenting here mostly don't seem to have to do with the resource costs. Do what you have to do, but if you declare XEmacs unsupported the most likely outcome is that we will continue to provide an AUCTeX package, and XEmacs users will continue to go to you for help. And then you'll be back at the point you were when you decided to work outside of the XEmacs build infrastructure. I think we'd be better off cooperating on the basis of not trying to change the other project's internal policies, but that's just me, I guess. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta