Thoughts on XEmacs packaging (was Re: Making docdir configurable)
[It's time, I think, to move this to xemacs-beta]
Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in
xemacs-review(a)xemacs.org:
>>>>> "sb" == SL Baur
<steve(a)xemacs.org> writes:
sb> Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes in xemacs-review(a)xemacs.org:
sb> ...
>> I don't really intend to mess with the package layout (as
opposed to
>> the package hierarchy layout) at all; I personally think this whole
>> issue is fucked beyond the point of redemption.
These are strong words. If things are really this fucked up then they
should be fixed.
All of the changes I've made have been fairly conservative. If we
really needed to, it wouldn't take more than perhaps a day to undo
everything and return to a 20.4-style source tree. I pray we do not do
this. Recall that we went through that exercise to create 20.3.
When InfoDock sources get released in a few weeks, you should probably
take a look at how it uses packaging. It is a hybrid system,
half-way between monolithic 20.4 and packaged 21.x.
sb> Then how would you have done it?
Back when the discussion about the package system started (Chuck was
still around then), I posted a fairly complete concept for one; this
was probably in 1997, I don't know if anyone still has archives.
This was on the old xemacs-beta-discuss, right? I no longer have
archives but I recall the message you are referring to. I thought
long and hard about it as I first started coding things up.
I even started coding it, but when I asked for volunteers to help,
noone stepped forward. When the current system popped up, I assumed
nobody was interested.
I didn't know about the coding part. I vaguely recall[1] you mentioning
that you would code it yourself if no one else was going to do it, but
then you disappeared for awhile. If I had seen any code whatsoever, I
wouldn't have started a variant implementation.
It's not like there has been a massive investment of coding anyway.
Nearly all of the work has been organizational in nature.
The main insight is that XEmacs needs to know about package
versions,
and that there need to be several mechanisms to deal with them.
I know. I started to deal with this via an ill-defined `package-provide'
and `package-require' that never worked out.
Roughly:
- Several versions of the same package can coexist, if not in the
same
running XEmacs, then at least within its reach before any of them
have been loaded.
O.K.
- A new variant of REQUIRE would allow specifying a version or
minimum
version for it to succeed.
O.K.
- There needs to be a way to specify version preferences.
O.K.
- A package version would be able to associate or disassociate
itself
with/from a certain Emacs version.
I suppose. I really, really don't like code that decides what to do
based on an Emacs version.
Back then, I thought that symbolic links would solve the problem.
(They work well enough for our 200+-package software installation, for
which we have locally developed tools.) Today, I've concluded
(especially now that the NT port is around) that this information can
more flexibly be encoded in Elisp.
Yes.
The obvious symptom currently is that XEmacs doesn't know which
package an auto-autoloads.el file belongs to, and cannot deal with
several auto-autoloads.el files belonging to different versions of the
same package, short of coming up with a meaningless error message.
Right. I've never been happy about this currently works.
This is something I plan to fix once I have the time.
Share with us your thoughts on what The Right Thing to do is. Perhaps
you won't have to code it yourself.
I also think it's a mistake to spread a package over different
places
in a package hierarchies, and to require consistency of the
installation situation with the MANIFEST files.
The MANIFEST files were an accidental feature. There certainly isn't
a requirement that they be kept in synch, but it makes things somewhat
easier if they are.
With one directory per package, things like package deletion would
be much more simple, and access to auxiliary files could actually do
the Right Thing and ensure coherence between different parts of one
package.
That would be a departure from how things worked in XEmacs 20.x and
that is why I didn't do it that way. I am not adverse to changing
things now, and so long as the programming interface remains the same
or very similar, it shouldn't be a lot of work to migrate to a
different layout.
I like a plug-n-play XEmacs (and InfoDock for that matter) that I
can strip of useless bloat I will never use. I like that a lot. I
recognize there are some problems left to solve, but I think things
are better off now than they were in 20.x and the hardest work has
been done. The main problems are ones that existed in a monolithic
XEmacs too. Fine tuning things so it actually works well under the
conditions you mention above shouldn't be impossible (IMHO).
Footnotes:
[1] If one really trusts a blonde's memory. Gravity exists so that
blondes don't forget which way to get out of bed in the morning. :-)
--
雨降って地固まる
(Adversity builds character)