emacs-devel
[Top][All Lists]
Advanced

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

Re: CVS is the `released version'


From: Tom Tromey
Subject: Re: CVS is the `released version'
Date: Sun, 13 May 2007 18:43:33 -0700

>>>>> "David" == David Kastrup <address@hidden> writes:

David> The XEmacs package system basically consists of several pieces of
David> policy: a package layout which packages have to obey, a central
David> package repository where packages are checked in via CVS and built,
David> servers populated from this repository and mirrored.

FWIW, package.el does require a specific layout of the package.  This
could be changed -- package.el is reasonably small -- but so far I
didn't see a need.  Essentially it requires everything (.el files, the
info files and also a dir file) in the top level.  It also mandates a
couple file names, the main one being the .el file that holds the
"define-package" call.

David> XEmacs policies, however, prohibit the distribution of packages not
David> built with the XEmacs-specific build tools.

package.el by contrast does not have a build tool :-)

David> The problem is that there are not that many great things around that
David> are not already integrated into Emacs.

I respectfully disagree.  I'm regularly using a couple great packages
that for whatever reason, AIUI, will never be integrated into Emacs
(VM and BBDB).  There's also things like muse, planner, emms, RLX,
dvc, etc -- some of which may be integrated someday, but meanwhile it
would be nice to have a simpler way to install them.  Finally there's
the issue of Emacs' release cycle -- frequently it would be nice to
update an Emacs package like Gnus to some intermediate release.

David> With all that policing, the administrative burden is actually more
David> than getting some Lisp file accepted into the Emacs core tree.

package.el is tied to ELPA, the Emacs Lisp Package Archive.  My plan
here is to turn this into a project hosted on savannah or the like,
run it as a free software project is run, and then give the major
package maintainers login access.  IOW, you could update the AUCTeX
packages yourself.

For smaller packages, uploading is trivial if the package meets the
packaging guidelines.  I have it bound to a key in Gnus :-).  This
sort of thing can comfortably be done by anyone with ELPA admin
access.

Tom




reply via email to

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