[Top][All Lists]

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

Re: ELPA policy

From: Achim Gratz
Subject: Re: ELPA policy
Date: Sun, 08 Nov 2015 18:18:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

John Wiegley writes:
> I would in fact like to see more packages move from core into ELPA, although
> I'm not eager to do so willy nilly. Some packages now in Core are just fun, or
> should be there because people are used to them being there, even if today we
> wouldn't necessarily add that package to core.

I've proposed this before, but I guess I should run it by you again (and
warn you it wasn't favorably received):

The current definition of "core" is that the sources live inside the
Emacs repository.  Several of the larger core packages like Org, CEDET
and Gnus are already largely developed outside Emacs, for instance
because the developers want to keep them compatible with different/older
Emacsen and need to be synced into Emacs sources to make them "core"

I posit that the only thing that actually matters for something to be
considered "core" is that authors of other packages can rely on the
(stable) API provided by these packages to be available in an Emacs as
it gets distributed and no installation of further packages or software
is necessary, neither by the sysadmin nor the user.  If so, instead of
keeping the "core" sources all in Emacs, they could equally well be
living in ELPA and be pre-installed into the distribution, or installed
into the Emacs build tree as submodules or subtrees.  The most radical
(and likely most controversial) thing to do would be to move everything
to ELPA that isn't needed to bootstrap Emacs.

Doing this would need some as of yet non-existing infrastructure to get
the chosen ELPA version of each package built into the distribution, and
facilities for sysadmins and users to update (but not disable) the
"core" packages at the system level or in their private directories.
Emacs may eventually distribute some "non-core" packages also that
sysadmins or users could disable if they chose to not use them.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:

reply via email to

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