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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 14 Apr 2023 17:05:30 +0100
> Cc: Robert Pluim <rpluim@gmail.com>, 62720@debbugs.gnu.org, larsi@gnus.org, 
> 	Eli Zaretskii <eliz@gnu.org>, Philip Kaludercic <philipk@posteo.net>
> 
> On Fri, Apr 14, 2023 at 4:52 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > 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.

When you say "compatibility", you seem to have only one its aspect in
mind: that of Eglot.  But that is not the only aspect of the previous
behavior, and I, at least, must consider those other aspects as well.

That package-install doesn't upgrade core packages was how it behaved
in past versions.  In Emacs 29.1 I hope we will allow at least
overriding that by user-level means, so we will be closer to your
(Eglot-centric) ideal, without also breaking the other aspects of
previous behavior, since there are other core packages on ELPA besides
Eglot, and some of them were in that state before Emacs 29.

And that is all we can reasonably do at this time, guiven how close we
are to the release.

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

"The same thing" for Eglot means "not the same thing" for other core
packages.  So you are in effect calling for breaking everyone else to
cater only to Eglot.  That is not going to happen, for more than one
reason.