1:24 p.m.
Hello,
it's not the first time this topic has been discussed, but a recent
thread on comp.emacs.xemacs and its solution have made it more
pressing.
The situation at the moment is that Reiner has, after a user had
problems in getting a working AUCTeX on XEmacs, used the Makefile
target in our distribution to create such a package and put it online,
which the user (who did not have recourse to the required build tools)
could then just install.
I think it is pointless to force users to recompile. XEmacs packaging
policies mean that Uwe, the current AUCTeX package maintainer,
basically has to take a working package, unpack it, rearrange the
results in a manner that would match a typical source in the XEmacs
package source tree, check it in, write and maintain metadata, just in
order to arrive at the same package he started with, modulo mistakes
and different versioning. Then _another_ person is responsible for
the actual build and distribution.
Even if Uwe had perfectly much time and energy available for that job
(which he hasn't), it is not likely that this way of processing will
cure more problems than it causes. And the persons responsible for
the problems introduced in this process are not core AUCTeX
developers.
I think that in interest of coherence and of the users, we should just
bite the bullet and put the XEmacs package up for download ourselves,
right from the official AUCTeX download site instead of hidden away on
the private ftp space of a developer.
The version numbers should make telling apart our XEmacs packages from
the "official" ones easy enough. We'll have to figure out what to
write in our installation instructions and release documents, though.
It may be reasonable to omit everything pertaining to building an
XEmacs package from the user-accessible documentation in the tarball,
and instead make that just part of the CVS archive.
The question is what to do with the version in the XEmacs package tree
and available from its servers.
There are three possibilities:
a) business as usual. Updates will occur when somebody has time and
is willing to do them. They involve quite a bit of manual error-prone
work.
b) stop updating AUCTeX altogether but keep it on the package servers.
c) remove it from the package servers.
It is actually the call of the XEmacs packagers how they want to deal
with that issue. But I don't think it serves AUCTeX development if we
try feeling responsible for the results of a process that is quite
outside the hands of the core developers. And I don't feel Uwe should
be held responsible for problems that should not be there in the first
place.
Distributing a standard package ourselves would solve most of those
problems, and maybe we can even cater for the metadata that would be
required so that our download directory can get listed in the package
download areas in XEmacs' package manager.
We do have to come up with a good idea about things like AUCTeX RPMs
for XEmacs, though. We can't have them install into the standard sumo
tree because of file conflicts with their AUCTeX versions, and they
are not really appropriate for site-packages, either, because that is
for local stuff.
Is there a package tree intended for OS distributors? Search order
with higher priority than the standard tree (and not conflicting with
it), but below site-packages tree? Something like dist-packages?
If not, we'll probably have to go with the site-packages tree.
Anyway, even while just putting this into RELEASE and README as a
separate "is available" item, we should in the long run also adapt the
documentation accordingly.
I don't think "how to build an XEmacs package" in its current
invocation should be part of the user documentation, as it requires
CVS access and does not work right off the tarball at the moment.
Maybe it should, but it seems more important right now to tell people
what to do once they _have_ gotten hold of a binary package, rather
than tell them how they could generate one themselves.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
4:02 a.m.
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> I think that in interest of coherence and of the users, we
David> should just bite the bullet and put the XEmacs package up
David> for download ourselves,
This is what I recommend (and have always recommended). This is what
VM does.
David> The question is what to do with the version in the XEmacs
David> package tree and available from its servers.
The version in the package tree should stay there. Anybody who gets
it from our CVS should know what they're doing (that's a normative
statement, not informative).
Whether tarballs should be available or not is up to Uwe, mostly, and
Norbert.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:31 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> I think that in interest of coherence and of the users, we
David> should just bite the bullet and put the XEmacs package up
David> for download ourselves,
This is what I recommend (and have always recommended). This is what
VM does.
David> The question is what to do with the version in the XEmacs
David> package tree and available from its servers.
The version in the package tree should stay there. Anybody who gets
it from our CVS should know what they're doing (that's a normative
statement, not informative).
I don't mind about the CVS. But doesn't what's in the CVS end up
automatically on the package servers (where nothing else is allowed if
I understand correctly) and in sumo tarballs? People using the
package servers will assume getting the latest version, and of course
people using the sumo balls are counting on something reasonably
up-to-date, too.
Whether tarballs should be available or not is up to Uwe, mostly,
and Norbert.
"available" means being put to package servers and sumo, right? So
the process of feeding them _is_ one using manual intervention. I
really think that the XEmacs board should review its decision not to
accept any packages built in a non-orthodox way, and allow for
case-by-case exceptions. In AUCTeX's case, the additional two-person
pipeline causes additional workload and can't significantly contribute
to package availability and quality.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
1:36 p.m.
* David Kastrup <dak(a)gnu.org>:
Hi!
I don't mind about the CVS. But doesn't what's in the
CVS end up
automatically on the package servers (where nothing else is allowed if
I understand correctly) and in sumo tarballs? People using the
package servers will assume getting the latest version, and of course
people using the sumo balls are counting on something reasonably
up-to-date, too.
This depends on my lazyness (and I've been very lazy or side tracked
in recent months). If people want to be up-to-date, they should
either CVS update the sources or use pre-released packages which I try
to build close to changes in the package tree.
> Whether tarballs should be available or not is up to Uwe,
mostly,
> and Norbert.
"available" means being put to package servers and sumo, right? So
the process of feeding them _is_ one using manual intervention. I
really think that the XEmacs board should review its decision not to
accept any packages built in a non-orthodox way, and allow for
case-by-case exceptions. In AUCTeX's case, the additional two-person
pipeline causes additional workload and can't significantly contribute
to package availability and quality.
You know, I personally don't mind removing AUCTeX from the list of
supported official XEmacs packages and instead tell people where to
find it, let's say on our web site.
I don't know about our disk capacities at tux.org, but I would guess,
it's even possible to put the tarball close to the official packages.
Still, someone will have to renew them, so you may still end up with
people using old versions of your software.
norbert.
6:58 p.m.
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> The version in the package tree should stay there. Anybody who gets
> it from our CVS should know what they're doing (that's a normative
> statement, not informative).
David> I don't mind about the CVS. But doesn't what's in the CVS
David> end up automatically on the package servers (where nothing
David> else is allowed if I understand correctly) and in sumo
David> tarballs? People using the package servers will assume
David> getting the latest version, and of course people using the
David> sumo balls are counting on something reasonably up-to-date,
David> too.
I think one important point is SUMO. Most users I know, (and who are
not experts) usually will tend to the SUMO version. I am just in the
middle of trying to get the new auctex 11.82 version to work (the
problem are mostly caused by the fact that preview is now included
within auctex), however the delay is only caused by the lack of my
time.
I agree with David that it would be ideal if the core auctex
developers would control the version to be shipped with xemacs,
because well they are the maintainers and the even have made the
(nice) effort to produce a xemacs-pkg themselves (the only other lisp
package) I know, which does this, is x-symbol (vm seems to work
differently). I have not even participated in any discussion
concerning adding that feature (generating the xemacs-pkg).
Unfortunately no other user came up as volunteer as a auctex packer.
It is most unfortunate that xemacs, ui, pui does not manage 3rd party
pkg, as does dkpg and rpm.
> Whether tarballs should be available or not is up to Uwe,
mostly,
> and Norbert.
However since I think that SUMO is important I will try my best to
provide a sync with 11.82 and can hope that in the future things will
be more smooth on my side (and that the structure of auctex will stay
the way it is at least for the near future.)
Uwe
7:52 p.m.
Uwe Brauer <oub(a)mat.ucm.es> writes:
I think one important point is SUMO. Most users I know, (and who are
not experts) usually will tend to the SUMO version.
Yup. That's also what most OS distributors package.
I agree with David that it would be ideal if the core auctex
developers would control the version to be shipped with xemacs,
because well they are the maintainers and the even have made the
(nice) effort to produce a xemacs-pkg themselves (the only other
lisp package) I know, which does this, is x-symbol (vm seems to work
differently). I have not even participated in any discussion
concerning adding that feature (generating the xemacs-pkg).
preview-latex has always installed itself into the XEmacs package
tree. Installing into a separate place and packaging that place was
basically all what was needed apart from adapting the procedure to
AUCTeX.
It is most unfortunate that xemacs, ui, pui does not manage 3rd
party pkg, as does dkpg and rpm.
I was of the impression that one can deal with single packages, it is
just that the package browser will not find the packages on the
server, obviously.
Let me see: M-x package-admin-add-binary-package RET should probably
do the trick.
>> Whether tarballs should be available or not is up to
Uwe,
>> mostly, and Norbert.
However since I think that SUMO is important I will try my best to
provide a sync with 11.82 and can hope that in the future things
will be more smooth on my side (and that the structure of auctex
will stay the way it is at least for the near future.)
Probably more or less. We are not moving things around for the mere
fun of it: upstream also has a CVS, and moving is not really a nice
operation.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
8:10 p.m.
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> I was of the impression that one can deal with single packages, it is
David> just that the package browser will not find the packages on the
David> server, obviously.
David> Let me see: M-x package-admin-add-binary-package RET should probably
David> do the trick.
It does not at least not for me on 21.4.17 mule/nomule.
9:44 a.m.
>>>> "Uwe" == Uwe Brauer <oub(a)mat.ucm.es>
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.
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. If
somebody wanted to get this right and make it more convenient, I'm
sure XEmacs people would be willing to help with it, 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.
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, and would
require us to keep track of whether that package continued to work
with any future changes in the package infrastructure. That's not our
job IMO.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:04 p.m.
New subject: [AUCTeX-devel] Re: Future AUCTeX distribution
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Uwe" == Uwe Brauer
<oub(a)mat.ucm.es> 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
11:54 a.m.
New subject: [AUCTeX-devel] Re: Future AUCTeX distribution
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> Too bad the package developers might be the better choice
David> at times.
I don't have time for this. You're not interested in cooperation,
fine. Do your thing your way, we'll do our thing our way.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:30 p.m.
New subject: [AUCTeX-devel] Re: Future AUCTeX distribution
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> Too bad the package developers might be the better choice
David> at times.
I don't have time for this.
So has nobody else from the XEmacs team. Which is the reason we, as
the package developers, are trying to find a tolerable way to do the
work for you.
You're not interested in cooperation, fine.
Last time I looked, "cooperation" did not mean one party doing all the
work in the manner prescribed by another party.
Do your thing your way, we'll do our thing our way.
If you actually did your thing your way, that would be dandy. The
problem is that you want us to do your thing your way. We already do
your thing, just not your way. And that is not because of spite and
malice, but because your way does not fit our procedures which have to
cater for more than just XEmacs.
Whatever. At least this thread has made clear that the only sensible
thing _we_ can reasonably do for the sake of XEmacs users is to
provide a standalone package for download and install. It is a pity
that your policies prohibit you from distributing it, but after all,
it is your own foot you are shooting.
I'll probably come back here to ask how to properly produce a
"package-index" file that would permit XEmacs users to access our
distribution site with the XEmacs package browser.
Thanks for making XEmacs what it is,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
4:06 p.m.
New subject: [AUCTeX-devel] Re: Future AUCTeX distribution
>>>> "David" == David Kastrup
<dak(a)gnu.org> writes:
David> I'll probably come back here to ask how to properly produce
David> a "package-index" file that would permit XEmacs users to
David> access our distribution site with the XEmacs package
David> browser.
"Properly" is done with our Makefiles; AFAIK they are the reference
implementation, there is no separate specification. So forget
"proper", just hack up something good enough.
For that, you simply need to substitute the variables in the XEmacs
AUCTeX Makefile for the corresponding variables in the existing
package-info.in, both of which you can get from Uwe, then compute and
substitute few simple data like package size, MD5, and date produced,
and wrap it in
;;;＠＠＠
(package-get-update-base-entry (quote
;; edited package-info.in goes here
))
Then save to "package-index.LATEST.gpg".
AFAIK the funky ";;;＠＠＠" comment is part of package-index syntax, and
it can't hurt. IIRC size and MD5 are computed on the tar.gz file. Done.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6886
days inactive
6889
days old
11 comments
4 participants
participants (4)
-
David Kastrup -
Norbert Koch -
Stephen J. Turnbull -
Uwe Brauer