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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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: every ELPA package we want to include will have
a branch in `emacs.git` (e.g. with name `elpa/[PKGNAME]`) and in Emacs's
`master` branch we will add git submodules which refer to (specific
revisions on) those branches.

This way a Git checkout can also contain those ELPA packages.  We can
easily control which version of a package is included into any given
version of Emacs because git submodules refer to specific revisions.
And those `elpa/[PKGNAME]` branches can easily kept in sync with
the corresponding branches in `elpa.git` (and upstream if applicable).

>  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 after which we simply have to add that directory to the default
value of `package-directory-list`.


        Stefan