Re: Getting start on Emacs 25.2

[Phillip Lord]

John Wiegley <address@hidden> writes:
> Speaking of whiche, one the first things I'd like to achieve toward 26.1 is
> the new ELPA infrastructure we've discussed in the past -- the ability to
> designate ELPA packages as (1) "usable by core" (2) "included in the
> distribution tarball" and (3) "installed using package.el". I've been calling
> these "core ELPA", "tarball ELPA" and "package ELPA", respectively.

I'm still slightly confused by this, so let me have a go at
clarification. First some terminology, because I think things are
getting confusing with the term "package":

 - package -- a set of lisp files, `provide`ing a co-ordinated set of
   features. Examples: gnus, seq.el, vc

 - Core format -- a package laid out according to current core
   directories -- i.e. source in a (nested) dir in the lisp dir, test in
   another. Examples: gnus, org
   
 - package.el format -- a package with headers, and directories laid out
   for package.el. Examples: gnus and org (again!)

 - ELPA -- the set of package.el format packages available on the web,
   with associated repo.

Currently, we have

 - packages in core format in Emacs Git and build
 - packages in package.el format in ELPA git and build
 - a few packages in both (org and seq I think)

In the future I see:

 - packages in core format in Emacs git and build. Those packages
   involved in bootstrap, startup and package.el itself have to remain
   in this state. Everything else can, but need not.
 - packages in package.el format that are guaranteed to be present in
   any Emacs download.
 - packages in package.el format that are present in any download and
   also available on ELPA.
 - packages in package.el format that are available only on ELPA.

My belief is that most packages would be better in package.el format,
although I don't see an immediate case for re-formatting them wholesale.

I'm not sure I understand your distinction between "core ELPA" and
"tarball ELPA".

> Phil Lord has already done some further investigations down this road, so soon
> we'll have an open discussion on how best to achieve this technically.

So far, I've added the ability to (partial) support for packages in
package.el format directly to the Emacs build, which seems the obvious
way to support points 2 and 3 from above.

Phil