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

David Kastrup writes: sjt> I conclude that if the CVS tree Makefiles are part of the complete sjt> source, a separate source package should be constructed. Sure, but for me that's a non-starter. If you succeed in convincing me that the process described below does not satisfy the GPL, then either the project will get source packages that do satisfy the GPL in letter and spirit, *batteries included*, or it will stop distributing binary packages, or I will leave the project. However, I believe that our "binary" packages satisfy both the letter and spirit of the GPL concerning source. Specifically, I personally modify packages in place, rebuild them, and continue work, and we often get patches from users who apparently do the same. I believe that modification and rebuild of the binary received is all that the GPL asks of a source distribution. This requires a bare minimum of effort: M-x find-library, C-x C-s, M-x byte-compile-and-load-file, M-x update-autoload-file, M-x byte-compile-file RET auto-autoloads.el. No scripts are used, therefore no script need be distributed. Installation is done by "tar x", not by "make install". As for "preferred form", it clearly refers not to the organization of the files into directories or the presence of Makefiles, but to the language of the content of files that *are* present. The only remaining issue are the package-info files, but they have no user-servicable parts. Of course if the user *wants* to change them, they're just Lisp files, and he can. That is exactly what I would do if (for example) I wanted to tag a locally-modified installed package as modified. I would *not* do that in package-info.in! I see no reason to suppose that the package-info.in form is any more "preferred" *here*. (In the context of the CVS version it is, but that is a different Work.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta