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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: daniele@grinta.net,  stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Tue, 15 Dec 2020 15:11:47 -0500
> 
> > 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).

Are you talking about something that already works, or about something
that _could_ work, after some changes?  If the former, then where's
the code to support it?

> > 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.

That won't fly, because usually some previous version of that same
package did work with Emacs-N.  And since packages don't usually have
a stable branch and a development branch, how to bundle them and how
to upgrade them later becomes a mess.  Some of that was discussed in
this thread, for example:

  https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01000.html

> > 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.

We are being asked to "start doing it" right now in emacs-27.  I'm
sorry, but this is not a serious suggestion, given the state of the
affairs and the number of issues for which we just think we know how
to solve them.  Like that pianist that knows how to play the piano,
but has never tried.

And what does it mean "start doing it", really?  We prepare a tarball
only once we start a pretest, by which time it's too late to
experiment with untested machinery.  And doing that on master makes no
sense, because there are no tarballs.  So here's one more issue for
us: how can we ever get this stuff to maturity if we cannot test-drive
it until it is too late?