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

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

> Doesn't package.el install stuff under ~/.emacs.d/elpa/ ?
> If so, what happens with installed Lisp files under /usr/share/ ?

The way package.el works, is that it collects all the packages it can
find installed locally under `package-directory-list`.  This list can
contain many different versions of the same package.  `package-activate`
then choose which ones of those packages to activate, under the
constraint that only one version of each package can be activated in
a given session (and under the additional constraints setup by the user
in `package-load-list`).

This was designed so that a sysadmin can install a bunch of packages and
users can then make use of them without being stuck using all those the
sysadmin has chosen to install, not stuck with the version that the
sysadmin installed.

If the Emacs tarball bundles packages, it would basically act as "a
sysadmin" in this regard.  Users could still override that set of
bundled packages with older/newer versions or even choose not to
activate some of the bundled packages (tho I'd hope that the packages we
choose to bundle are clean enough that this would never be useful, just
like it's not considered useful for the user to be able to remove stuff
from lisp/loaddefs.el).

> And what about the relation between the version in ELPA and the
> branches/versions of Emacs in the Emacs repository?  IOW, how will a
> package that needs Emacs version N+1 work with Emacs version N?

What about it?  The packages bundled with Emacs-N+1 would *not* be in
the `package-directory-list` of Emacs-N (and vice-versa), so there'd be
no particular issue at stake here.

> Bottom line, I feel that there's some kind of "trust us, it will be
> fine" attitude here, whereas I would expect careful investigation of
> all these aspects and some description of the procedures.

AFAIK all the investigation that can be done has been done.  I don't
doubt that there will be issues to resolve, but I don't think we will
find them before we actually start doing it.


        Stefan