Re: [AUCTeX-devel] XEmacs packaging/whatever.

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-06-18) writes:
>
>> I am not convinced (even after some pretty ugly discussion over
>> that on xemacs-beta) that this actually is enough to satisfy the
>> GPL source provision, so I have asked the FSF copyright clerk about
>> it.
>
> Would it be a problem to simply dump our doc/ directory into the
> man/ directory of an XEmacs package?  By doing a `find
> /usr/share/xemacs21/xemacs-packages/man/' I can see other packages
> which have Makefile's or README's in man/.

Well, a non-functional Makefile does not really fit the "preferred
form for modification" moniker.

The way I see it, we have the following choices:

a) include only the source files themselves without any build
structure, which is the way XEmacs does it with its own packages
AFAICS (third-party packages may be different).

b) include a set of working Makefile and similar that is the result of
running ./configure with options suitable for building an XEmacs
package.  The Makefile should not contain absolute paths (probably
hard to do), or at least have them easily overridable.  We would not
include Makefile.in or configure, as they would then offer nothing
additional to the downstream customer.

In a way, our leaving off autogen.sh and README.CVS from the tarball
is a similar step: it leaves the user with something that bootstraps
fine for his purposes and which will rebuild after modifying any of
the distributed parts.

c) declare the whole tarball the proper source.  What we include is
then our choice and not dictated by anything.

I am tempted to do "a)" without any explanation.  Whether this can be
called source or not we can clarify once we get some position from the
FSF, and it is not different from what XEmacs does, anyway.  If it is
not good for source, we can point this out afterwards.  If XEmacs
calls their packages "binary", so can we.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum