auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] XEmacs packaging/whatever.


From: David Kastrup
Subject: [AUCTeX-devel] XEmacs packaging/whatever.
Date: Sat, 18 Jun 2005 01:54:58 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Hi,

I am still thinking about what to do about XEmacs in connection with
our various packagings.

We should add advice for packagers (like FreeBSD and Debian) and, of
course, follow it with our RPM packages.

Up to now we had the strategy:
a) don't provide any AUCTeX for XEmacs
b) install an XEmacs-package like contraption for preview-latex into
the XEmacs package tree

Ok, but up to now we had XEmacs provide AUCTeX in its package-tree,
and never provide preview-latex.

So now we get conflicting version numbers from our AUCTeX installation
and the XEmacs package system.  Not installing into the XEmacs package
system, however, would have the disadvantage of losing the autostart
functionality.

I think what we probably should do is provide something that looks
like being installed into the package tree, with our version numbers,
in /usr/share/xemacs/site-packages (or so).  This will, in the case of
a tetex-based instead of a --without-texmf-dir installation, not be
perfectly equivalent to installing a binary XEmacs package.

Apropos binary XEmacs package: our pseudo preview-latex packages did
not install any documentation sources as far as I remember.  If we
want to mimick what is typical for XEmacs packages, we would have to
install the doc sources as well.  It is reasonably easy to create a
binary package that is as source-containing as the XEmacs packages,
namely missing the necessary build structure for recompiling and
repackaging the package.

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.  An
answer is still pending.  I think we might as well include the doc
sources in our XEmacs packages and/or pseudo-packages: if the current
practice of XEmacs development is ok, then we need not change anything
then (except possibly advice), and we match more closely what people
have come to expect.  If the practice is not ok, then we'll just have
to tell people that the original tarball counts as source and should
accompany the binaries whenever they get distributed.

I am not sure I want to put any explanations of that kind into our
documentation as long as I have no definite feedback from the FSF.
But I also want to avoid XEmacs developers pointing to AUCTeX as an
example of the FSF distributing stuff in that form, unless I really
get the ok for that from the copyright clerk.  Call me paranoid.

If we put something like

    The XEmacs binary package is to be viewed as that: a binary for
    which the source is AUCTeX's source tarball.  Since the binary
    package has the same form and content as XEmacs packages from the
    package servers, it appears equally suited to fit the "source code
    to be included" requirement of the GPL.  Until we get a definite
    statement on that, distributing the tarball along with the package
    might be a good idea.

into our explanations for the various packagings, the XEmacs people
might have some reason to accuse us of spreading FUD.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]