Re: [AUCTeX-devel] Re: Future AUCTeX distribution

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

>>>>>> "Uwe" == Uwe Brauer <address@hidden> writes:
>
>     Uwe> It is most unfortunate that xemacs, ui, pui does not manage
>     Uwe> 3rd party pkg, as does dkpg and rpm.
>
> Nope, it has nothing to do with "fortune"---it's by design.  pui is
> about helping XEmacs volunteers provide consistent support for
> packages we distribute.

XEmacs volunteers.  Too bad the package developers might be the better
choice at times.

> The burden of being pui-compatible on most 3rd parties is either
> 100MB of disk space for the package tree and a few minutes to update
> CVS before distributing a new binary package, or less than 100KB of
> space and at most a couple hours figuring out how to get all the
> infrastructure into the right place relative to your source.

Sorry, but you are presuming that the package developer is going to
use the XEmacs package CVS as his sole repository after that.  And "at
most a couple of hours figuring out" is not what I call an invitation
for participation.

> If somebody wanted to get this right and make it more convenient,
> I'm sure XEmacs people would be willing to help with it,

You are always sure about that.  And it is always a surprise for you
when few actually do and when one has to dig up third-party people to
help with something they themselves don't actually know.  XEmacs
developers have their own priorities and limited resources, and
dealing with the situation is not made easier by you pretending it is
different.

> but 3rd party developers and users prefer to wait for somebody else
> to do it.
>
> This is all irrelevant to AUCTeX; AUCTeX is not "most 3rd parties",
> or at least it wasn't in the last public release.  If it's now
> possible to release a binary package of AUCTeX, then things have
> changed a lot.

Not really.  This situation is not particularly new, there was always
the offer to do this, it is just that I have recently formalized it
with a Makefile target.  This Makefile target is not black magic: it
just creates a separate tree, calls `configure' and `make'` with the
right options, then packs the results.  What has been done recently
was to create a setup that permits leaving the preview-latex TeX files
in the package tree.  But that was just to cater for preview-latex,
which never previously had been an integral part of AUCTeX, and which
never had any XEmacs packages around.

> Nevertheless, I don't think it's appropriate to put a package built
> by a non-XEmacs process into our FTP site; that would implicitly be
> a promise that it will interact correctly with our tools,

Get real.  The AUCTeX packages built by the XEmacs processes have so
far _all_ broken the promise to work correctly, because of various
reasons, code changes, version numbering problems and so on.
Downstream can't provide any help for it because they are not AUCTeX
developers and are not acquainted well enough with the code to know
what problems might be caused by themselves, and upstream has a hard
time figuring out what problems are caused by downstream instead of
the original work.  It's like repairing clockwork with mittens on.

> and would require us to keep track of whether that package continued
> to work with any future changes in the package infrastructure.

I can tell you that _your_ package of AUCTeX will break with future
changes in the package infrastructure.  AUCTeX setup is not trivial:
moving files relatively in the tree will break things, since various
files are set up to find others in relative file paths.  And that
means that the upstream configure scripts (which can't even be checked
into the XEmacs package CVS or be called in the build process) have to
be told the _final_ package layout in order to generate the right
configuration files.  Moving things around afterwards is going to
break things.

> That's not our job IMO.

If you weren't so lousy at _what_ your job is, we wouldn't have to do
most of it ourselves in the first place.  In the time and effort it
takes to disassemble an AUCTeX XEmacs package from upstream into its
pieces, rearrange them for CVS, make sure that removed files get
deleted, generate the appropriate XEmacs metafiles and so on, one
could quality check the complete upstream package 5 times over.

We are not doing all the work of assembling an XEmacs package
ourselves because we want to have fun.  We are doing it because there
is nobody around downstream that both would and could do so, namely an
XEmacs person.  At least Uwe _would_ do so, and because he does not
have the skill set for "could" as well, we cater for it upstream as
well as we can.  And providing a completed working package as an
"example" is pretty much "as well as we can".

So Uwe's job indeed is to figure out how to convince the XEmacs build
structure to produce a package identical to what the Makefile target
in AUCTeX already does.  If you decide to change your package layout
around and change your build scripts accordingly, the downstream
AUCTeX will immediately stop working because it _depends_ on the
relative structure of the file layout told to `configure' for finding
its files.  There is no sensible place where one can change this
except in the upstream Makefile and other files that can't even be
checked into the XEmacs package CVS tree because they would conflict
there.

Whatever.  It seems like the course AUCTeX needs to take for its
XEmacs users is to provide a separate XEmacs package upstream and tell
people to use that.  We certainly will not stop providing Uwe or
whoever else with whatever help we can for producing a basically
unsupported downstream package, but in my book you are using him as a
fig leaf to pretend everything in the XEmacs package server policies
is beautiful.  So I am not even sure he is actually doing you a favor.
And it is not a one-time job he is doing, but something that continues
to cause work in future, work taking time and effort, work that can go
wrong, and work that is actually redundant since packages are already
produced upstream.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum