emacs-devel
[Top][All Lists]
Advanced

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

Re: Integrating package.el


From: Ted Zlatanov
Subject: Re: Integrating package.el
Date: Mon, 04 Jan 2010 11:55:04 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.90 (gnu/linux)

On Sat, 02 Jan 2010 21:38:58 -0800 Phil Hagelberg <address@hidden> wrote: 

PH> I've actually been thinking in even more incremental steps. Installing
PH> package.el in Emacs without altering any of the existing Emacs code
PH> would be an easy first step and would give some immediate benefit in
PH> terms of packages that are not included in Emacs.

Agreed.  I think it's mature enough and would benefit from the wider
exposure.  But at that point I think it becomes important to separate
the repository into "Emacs supported," "Emacs unsupported," "ELPA," and
any others deemed necessary.  Then the Emacs-related repositories can be
managed by Emacs maintainers and developers and hosted within the Emacs
repo while ELPA can remain independent.  

Can package.el support that?  It looks to me, from reading the current
source, that it's limited to a single repository.

PH> The next step would be to work on package submission. If the centralized
PH> system has a list of packages mapped to a list of DVCS repositories,
PH> they could be polled periodically and all tags matching a certain
PH> convention (say, starting with "v" and followed by a dotted number
PH> series) would be treated as package. That version would then be
PH> processed and published to a downloadable location for clients to pull
PH> in.

This should probably be a per-repository policy and process.

PH> I wasn't thinking about integrating packages that Emacs already contains
PH> until after these steps were complete. One thing that may be infeasible
PH> but would certainly simplify things a lot would be if we spun off
PH> packages like org-mode into their own separate DVCS repository and
PH> removed them from the Emacs source tree before making package.el treat
PH> them as packages. However, this may cause some unwanted chaos; I don't
PH> want to barge in and create a lot of work for people. It might also
PH> imply that network access would be necessary to perform a full build of
PH> Emacs since it would have to download bundled packages at compilation
PH> time. Not sure if that is a serious problem.

I don't know about the other packages that come with Emacs, but Gnus
could probably benefit from package.el-style installation (I don't speak
for the Gnus project, though, so I can bring it up on the mailing list
if necessary).  A better setup process for Gnus would be really nice,
though.  The usual pre-install and post-install scripts you find in RPM
or DEB would help.  I suspect many other packages would benefit from a
better setup process through package.el.

Ted





reply via email to

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