Re: decision on moving core packages to ELPA; also move to obsolete?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen_leake@stephe-leake.org,  daniele@grinta.net,  emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 13:35:01 -0500
> 
> > Here's what I think we should have working to start bundling ELPA
> > packages:
> 
> Then I think the "git submodule" approach proposed earlier by Andrea
> is the better solution

(I also proposed to use "git submodule"...)

> every ELPA package we want to include will have
> a branch in `emacs.git` (e.g. with name `elpa/[PKGNAME]`)

It's the other way around: each package in elpa.git will have branch
named emacs/PKGNAME.  Right?

> and in Emacs's `master` branch we will add git submodules which
> refer to (specific revisions on) those branches.

Yes.

> >  3. Users
> >
> >     We need a clear picture of how this Emacs will be installed and
> >     used, both when installed from a distro and when built locally
> >     from the source tarball.  Maybe there's nothing to discuss here,
> >     but I at least don't yet have such a clear picture.  It should be
> >     possible to install, upgrade, and downgrade such packages, as much
> >     as possible using the same package.el commands as for unbundled
> >     packages.  As a minimum, AFAIU we will need to provide a directory
> >     in the tarball/installation that will have the same role as
> >     ~/.emacs.d/elpa/, because a tarball cannot possibly install files
> >     in the users' home directories.
> 
> We will place the submodules under some `elpa` subdirectory of our
> choice

Why not under lisp/ ?

And what directory will be the parent of that elpa/ subdirectory you
propose, when Emacs is installed?

> after which we simply have to add that directory to the default
> value of `package-directory-list`.

Note that this is not a single directory, but at least 2 different
ones: we need to support both running Emacs uninstalled, from the
source/build tree, and running an installed Emacs.