"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> XEmacs.rules (for example) is not part of the package builder source,
Wrong example. XEmacs.rules is part of the package builder, common to
all packages, and useless without the full package infrastructure.
Sigh. Yes, wrong example. I don't use XEmacs at all, so something
wrong stuck. Taking a look at
3.2.2 Control Files
Each package source must contain a number of control files in the
top-level directory. These files in general can be created and then
ignored, except for a few variables that need to be updated when new
versions are released. In most cases even adding, renaming, and
removing library source files can be handled by generic rules.
The package control files include
Must set a few `make' variables used by the administrative
utilities, and defines a couple of package-building targets to
depend on appropriate targets defined generically in
`XEmacs.rules'. It may also provide various variables and rules
to transform the source tree structure into that expected by the
Provides a template for package information to be provided to
the administrative utilities. Static variables that are rarely
changed (such as the package's name) are entered as
literals. Some variables are generated by the build process
(build dates and MD5 checksums) and are automatically filled
in. Finally, some variables that change irregularly (dependences
and even version numbers) are set as `make' variables in the
It is quite clear that you are talking here about "each package source"
and about package specific control files. There are a few more
mentioned, but ChangeLog is not part of the build procedure, and the
others are autogenerated and thus need not be distributed.
> but is rather a control file specific for each particular
> It is a required part for building the package in the preferred way
True, as is true for programs such as Debian's debhelper, which is not
distributed with any Debian package (other than itself). Your mistake
is failing to realize that the *package* is not the *program* that the
And so on. Come on, you recognized "wrong example" right at the start,
and you still go on making an argument?
The "preferred way" for building the distribution medium
refer to is to check out the whole CVS tree (which is of course
available by anonymous CVS), and build there. That is the *only*
supported way to build an XEmacs package.
Which means that the standalone XEmacs package don't come with source,
since essential files are missing. If you remove a particular package
from CVS, the binary package distribution is not sufficient for putting
that package into a private build tree and rebuilding. So you need a
source distribution path meeting the GPL conditions.
In particular, *we do not support building packages against an
/installed/ tree*. (If you know what you are doing you could check
out the Makefile and only check out the transitive closure of the
REQUIRES in the Makefile.) According to your interpretation that the
tarball is the program, the only practical way we could comply with
the GPL is to distribute the entire package source tree with each
No, the package-specific part of the source tree that can't be readily
autogenerated from the final package.
 For some value of "with" that satisfies the GPL, of course.
Surprise, surprise, that is what everybody else does. That's what
source RPMs, source debs and so on do.
> Since the package-specific control files required for building
> package are rather small, it is not obvious to me why you prefer
> smearing egg all over your face time and again over including them
> in the package.
Because any non-trivial package will fail to build without much of the
rest of the tree,
Nobody (in particular the GPL) is bothered about the
non-package-specific parts of the tree. Various Emacs Lisp applications
are distributed without Emacs (without which they don't make sense).
and a trivial package doesn't need XEmacs.rules to modify and
I think we established already that XEmacs.rules was the wrong example.
David Kastrup, Kriemhildstr. 15, 44793 Bochum
XEmacs-Beta mailing list