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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: daniele@grinta.net,  stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 13:50:10 -0500
> 
> >> > Are you talking about something that already works, or about something
> >> > that _could_ work, after some changes?
> >> The sysadmin scenario I described is one that has worked pretty much
> >> from the beginning of package.el.
> > That's not what I asked.
> 
> Then I don't know what you asked :-(
> Could you clarify your question?

Here's how we got to that:

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

My question was about the last part: it seemed to describe how things
_should_ work, but I'm not sure we already have that implemented.  Do
we?