Uwe Brauer writes:
>> On Mon, 30 Jul 2012 00:27:19 +0900, "Stephen J.
Turnbull" <stephen(a)xemacs.org> wrote:
> There are two real issues with packages. The first is
> the $prefix/lib vs. $prefix/share mess, which mostly
> affects users rather than developers, but needs fixed
> (and is gradually improving in 21.5). This is a
> difficult issue because it crosses versions, and 21.5
> is not yet ready to replace 21.4 for many users.
I am not sure what you mean.
I mean that in 21.4, configure assumes that XEmacs's package Lisp will
be installed into something like /usr/local/lib/xemacs, and in 21.5,
the corresponding default is /usr/local/share/xemacs. This change was
made for FHS conformance but it's annoying to those who use both.
For me the structure
is cumbersome. I would prefer the other way around
That's a completely different issue. Lobby Mike Sperber about it.
He's been refusing to consider a change in this for a decade or so.
I'm not going to work on it myself because it's really not that big a
deal to work with, but changing this looks like it is going to be
Another point is the numbering system. I think it would be
best to adapt a debian like numbering scheme.
This doesn't really make that much sense. On the one hand, RMS
refuses to put versions on libraries developed within Emacs. (Which
makes sense because Emacs developers feel free to change APIs around,
so the only version that really makes sense is that of Emacs itself.)
We use the version numbers the authors provide
For externally maintained packages we already mostly do. But for many
packages there is no external version.
I don't really see a point in maintaining an XEmacs release number
once that's been done. What we should do instead is bake the
Mercurial revno into the package somewhere, and provide APIs and
commands for extracting them. (We actually already have most of
what's needed in the pkginfo library, but they're not well documented
and even more poorly advertised.)
This would also help to know which packages are outdated and
which are not.
M-x list-packages will tell you that.
Last but not least if we had something like debian's alien,
a pkg which converts a bundle of lisp files into out pkg
system, that would be a great leap forward.
I don't see how it would be a "great leap". The part of the process
that can be automated is both simple and well-documented in the
LispRef "Creating Packages" node. Anything more that is required
beyond copying the example files and filling in the blanks with data
relevant to your package is not going to be automatable.
> I gather you haven't noticed ELPA yet, either.
BTW how compares our pkg system with ELPA?
We won't know for several years. I think they're going to run into
big problems in a few years as ELPA expands. Currently almost all
packages have no dependencies outside the Emacs core. That makes
generating an ELPA package simple. But this simplicity is deceptive,
because (1) as the core changes, the packages will need to be updated
and they'll experience the same kind of skew problems we do, and (2)
as packages start to depend on each other, they'll need to add
dependencies. I expect some massive flamewars over (1) because the
Emacs maintainers' position is effectively that there's only one
release of Emacs that they need to worry about compatibility with, and
that's the upcoming one. And packages aren't their problem.
On the other hand, ELPA could work very well if they adopt flexible
rules for incorporating new packages into Emacs so that "only depends
on core" restriction continues to be satisfied for the majority of
Finally, there's the wild card that there's more than one ELPA. GNU
ELPA insists on the same conditions that apply to Emacs (including
copyright assignment, IIRC). Other ELPAs do not. This could get very
messy if there's version skew or dependencies across ELPAs.
XEmacs-Beta mailing list