[Top][All Lists]

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

Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX

From: Stephen J. Turnbull
Subject: Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.
Date: Thu, 06 Dec 2012 10:01:21 +0900

I've nuked the emacs-devel CC because what I have to say isn't really
relevant to Emacs itself, and only peripherally to ELPA.

David Kastrup writes:

 > The XEmacs package building is sort of an aggravation.

Indeed.  I know a few XEmacs users who appreciate it, but I admit that
there aren't all that many who have expressed any appreciation at all.

 > So it is not clear to me who the customers for the XEmacs packages we
 > compile actually are.

The customers are people who want the latest AUCTeX version at
release, rather than after wending its way through our release process
too, and are willing to accept the (slight but real) risk of
preventable breakage due to differences in build environments.

 > XEmacs itself boycotts our packaging efforts since we don't arrive
 > at the right layout in the canonical way.

It's just the same "consistent build environment" policy that Debian
uses for packages they distribute, but we don't have the level of tool
support (eg, for running configure, which would require Cygwin or MSYS
on Windows) in our build system needed to incorporate third-party
build processes.  It's technical issue at root, but not one that can
be resolved without effort we think is unjustified since there are
very few packages that require anything beyond an emacsen to build.
Unfortunately, I can assure you that there will be no serious effort
on our part to change that situation for at least a year, and probably

 > Removing [prv-xemacs] from the source distribution would be
 > seriously unfair since it is technically complex enough that
 > starting it from scratch would be quite hard: that would be several
 > man-months at least

I agree that we would definitely prefer that the XEmacs-related code
remain in the upstream source, but realistically, it wouldn't be
starting from scratch, since we should have some fairly recent version
of prv-xemacs.el in our tree already, and if not, we can get one

Once again, I would like to reiterate that the polite request from
XEmacs for continued support from AUCTeX is just that, a polite
request, which may be satisfied or not by the AUCTeX developers at
their option.  XEmacs has no complaints whatsoever about the support
we have received from AUCTeX in the past.  Rather, we apologize for
the confusion caused to users and the increase in support burden on
the AUCTeX community due to the lag in updating our package tree.

Sincere regards,

reply via email to

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