[comp.emacs.xemacs] AUCTeX 11.84 released
Stephen J. Turnbull
stephen at xemacs.org
Thu Jan 25 23:09:37 EST 2007
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.
> Or a file should be included that indicates where what should go.
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.)
More information about the XEmacs-Beta