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: stephen_leake@stephe-leake.org,  daniele@grinta.net,  emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 13:46:37 -0500
> 
> >> 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).
> > So we will have 2 copies of each package's Lisp files in the tarball?
> 
> No, just one, the one in the `emacs/elpa` directory.

So what did you mean by "the tarball will include the same file as
before in emacs/lisp"? which file will that be, and how is it
different from what will be in emacs/elpa?

> >> We could also place some or all of the bundled packages directly inside
> >> `lisp`
> > Now I'm confused: how 'lisp/' is different from 'emacs/lisp' you
> > mentioned above?
> 
> It's the same thing.  I just omitted to write the "emacs/" prefix that time.

Still confused: how is that different from the first alternative,
where you said the file will be in emacs/lisp?

> > What are the pros and cons of each of these 2 alternatives?  I think
> > we should carefully consider them before deciding which one we prefer.
> 
> Basically, the question is whether the autoloads of those ELPA packages
> are processed once and for all when we dump Emacs (like we do for all
> the packages that come with Emacs), or whether that's done during
> `package-activate-all` (i.e. between `early-init.el` and `init.el`).
> 
> Doing it at dump time gives better startup times, at the cost of making
> it impossible for the end-user to prevent activation of a package (they
> can still undo the activation after the fact, of course, but that needs
> to be done in ad-hoc ways).
> 
> I think as a first step we should keep those bundled ELPA packages more
> like normal ELPA packages (i.e. activate them from
> `package-activate-all` rather than when dumping Emacs).  We can later
> revise this (even on a per-package basis) once we have more experience.

I actually like the other alternative, because people will want faster
startup, and because it makes no sense to let users disable bundled
packages.  If we think people will want to disable a package, we
shouldn't bundle it.