bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

["João Távora" <joaotavora@gmail.com>]

On Fri, Apr 14, 2023 at 4:52 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Maybe you can answer this: if a user is setting up Emacs 28 in company
> > laptop machines regularly and does M-x package-install RET eglot RET there,
> > or has a script with (package-install 'eglot), should or shouldn't this
> > user, in your opinion, be allowed to do exactly the same, with the same
> > predictable results (in this case getting the latest Eglot), when she starts
> > doing the same in Emacs 29, which now contains Eglot as a built-in?
>
> Good point.  I think the answer is that we should distinguish "install"
> from "upgrade" (and offer a way to do both, of course).
>
> And I think we do want to break backward compatibility here (arguably we
> even can't not break compatibility), because the Emacs<29 semantics of
> `package-install` is "broken", since it does "install&upgrade" for
> non-builtin packages but not for builtin packages: either we keep that
> semantics and compatibility is broken when packages move to/from
> builtin, or we change that semantics and compatibility is broken by the
> change in semantics :-)

I would think it's too late in the game to break compatibility.
Naming aside package-install has certain behaviour that for a certain
set of inputs used to produce predictable things.
Now, for the same inputs it does nothing on Emacs 29.

I think it should do the same thing, not only because it's
nicer for the unsuspecting user, but also because trying to
protect this user from "unintentional" upgrade of certain "unstable"
packages, as it seems to be the idea here, is a losing game
anyway, just because dependencies.  Presumably, the packaging
system where it takes less than a day to fix release a bug fix and
deliver this to the archives, should be the protection.