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

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So now we are talking about changing the basic logic in
>> normal-top-level-add-subdirs-to-load-path and
>> normal-top-level-add-to-load-path?
>
> Not at all.
>
> What I'm suggesting is the following:
>
> - the tarball we build will include the same file as before in
>   `emacs/lisp`.
> - it will additionally contain a new directory `emacs/elpa` in which
>   each bundled package has its own directory (all in the normal format
>   of installed packages in ~/.emacs.d/elpa).

We might want to use git submodule to have the selected packages (and
the precise sha1 we want for their release) there.

This gives the advantage that everybody could obtain and test the
packages bundled with the Emacs release just checking-out all the git
submodules of emacs.git.

Developers with this system can also develop directly in the folder of
the bundled package given this is a git repo pointing to the original
branch in elpa.git.

Every time we decide to update a bundled package this would translates
into a regular commit in emacs.git updating the sha1 of the submodule,
so is very easy to keep track of these.

Yes thinking about I'm quite convinced submodule fits pretty naturally
what we are trying to do here, and would be a solution with no
additional dependencies and that does not require custom scripting.

  Andrea