[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"
anyway.
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.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
- Re: streams are cool, you could stream virtually anything!, (continued)
- Re: streams are cool, you could stream virtually anything!, Damien Cassou, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, Michael Heerdegen, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, Michael Heerdegen, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, Nicolas Petton, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, T.V Raman, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, Nicolas Petton, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, John Wiegley, 2015/11/04
- Re: streams are cool, you could stream virtually anything!, T.V Raman, 2015/11/04
- ELPA policy (Was: streams are cool, you could stream virtually anything!), John Wiegley, 2015/11/04
- ELPA policy (Was: streams are cool, you could stream virtually anything!), T.V Raman, 2015/11/04
- Re: ELPA policy,
Achim Gratz <=
- Re: ELPA policy, Eli Zaretskii, 2015/11/08
- Re: ELPA policy, Aaron Ecay, 2015/11/08
- Re: ELPA policy, Eli Zaretskii, 2015/11/08
- Re: ELPA policy, Dmitry Gutov, 2015/11/08
- New ELPA policy proposal (was: ELPA policy), Oleh Krehel, 2015/11/09
- Re: New ELPA policy proposal (was: ELPA policy), Artur Malabarba, 2015/11/09
- Re: New ELPA policy proposal, Oleh Krehel, 2015/11/09
- Re: New ELPA policy proposal, Artur Malabarba, 2015/11/09
- Re: New ELPA policy proposal, Wolfgang Jenkner, 2015/11/09
- Re: New ELPA policy proposal, Dmitry Gutov, 2015/11/09