unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: phillip.lord@russet.org.uk (Phillip Lord)
To: emacs-devel@gnu.org
Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>
Subject: Re: Getting start on Emacs 25.2
Date: Sun, 18 Sep 2016 21:48:49 +0100	[thread overview]
Message-ID: <87r38horwu.fsf@russet.org.uk> (raw)
In-Reply-To: <m2bmzmj57g.fsf@newartisans.com> (John Wiegley's message of "Sat,  17 Sep 2016 19:45:55 -0700")

John Wiegley <jwiegley@gmail.com> 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



  parent reply	other threads:[~2016-09-18 20:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-18  2:45 Getting start on Emacs 25.2 John Wiegley
2016-09-18 14:37 ` Eli Zaretskii
2016-09-18 16:28   ` Stefan Monnier
2016-09-18 19:41   ` John Wiegley
2016-09-18 21:23     ` Nicolas Petton
2016-09-19  6:37       ` Andreas Röhler
2016-09-19 16:37     ` Eli Zaretskii
2016-09-22 12:57       ` Phillip Lord
2016-09-22 15:15         ` Eli Zaretskii
2016-09-18 20:48 ` Phillip Lord [this message]
2016-09-19  7:09   ` Michael Albinus
2016-09-19  8:52     ` Phillip Lord
2016-09-29 19:23   ` John Wiegley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r38horwu.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).