[comp.emacs.xemacs] AUCTeX 11.84 released

Stephen J. Turnbull stephen at xemacs.org
Wed Jan 24 22:02:18 EST 2007


Glynn Clements writes:

 > It's not clear that a CVS repository and an FTP server running on the
 > same host are even "the same place". And, AFAICT, cvs.xemacs.org and
 > ftp.xemacs.org aren't even on the same network.

IANAL, but my feeling is that different protocols are different
places.  I would vocally :-) oppose XEmacs relying on the argument
that on the Internet all commonly used media amount to the same place.
That's not in the spirit of trying to conform.

 > > BTW Stephen, is there any real reason not to include the two files the
 > > crybaby is having a fit over, even if they're pretty much unusable
 > > outside of a CVS context from what I understand?  They can have some
 > > value as an example, I guess.
 > 
 > Given that the XEmacs "binary" packages are so close to being "the
 > complete source code" (they may even be so; IANAL, and, AFAIK, neither
 > is David), adding those files would mean that access to the CVS
 > repository should be a non-issue.

First, those files are definitely insufficient.  AFAICT David is
referring to the Makefile and XEmacs.rules (plus "template files," by
which I suppose he means package-info.in).  But XEmacs.rules calls
several Lisp files as well as including at least the Local.rules
Makefile.  Furthermore, in the case of AUCTeX, the xemacs-base package
is loaded at build time.  I don't see any point in a source package
which doesn't include those prerequisites, although it's not legally
required AFAICS (the xemacs-base source tarball would be available in
the same place).

My tentative conclusion is that the (comparatively ;-) sane thing to
do is to bundle up the whole source tree and call that the "complete
source", which can be used to build a variety of packages.

However, that would be in violation of the "preferred form for
modifying". ;-)

 > Personally, I'd suggest ensuring that one can rely solely upon the
 > argument that the binary packages really do consitute the complete
 > source code as defined by the GPL,

That cannot be done if the Makefiles are required by the GPL, because
they are non-functional in the installed context.  (Remember, in the
source tree, auctex is a child of xemacs-packages, whereas in the
installed tree it is always a grandchild.)  The GPL doesn't require
"documentation of the build process", it requires "the scripts *used*
to build the executable."  Adopting the "historical" interpretation of
"used" would be unacceptable to me if it's merely a way to dodge our
responsibility to provide full source in "the same place".

I conclude that if the CVS tree Makefiles are part of the complete
source, a separate source package should be constructed.




More information about the XEmacs-Beta mailing list