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

[Dmitry Gutov]

On 15/04/2023 14:19, Kévin Le Gouguec wrote:

> If I may throw in my ¢2: in Emacs ≤28, users never had a choice between
> a "installing the newest Eglot from GNU ELPA" and "requiring that Eglot
> be available, possibly not the latest & greatest".  They could only
> request the former.
>
> It's anyone's guess which of those two things users who cargo-cult those
> configuration lines would prefer, now that the question is up in the air
> for Emacs 29.  FWIW, I'd lean toward the latter: IMHO, package-install,
> resp. (use-package … :ensure t), merely suggest ensuring availability,
> not proactively ugprading to the latest (unlike say "package-update").
>
> So I wouldn't be shocked for package-install to be a no-op for :core
> packages, the semantics being "make sure the package is present,
> favoring any built-in version which presumably underwent lots of
> validation & stability fixes on the release branch".

I can easily buy this argument (and made it myself in a different form, 
I think), but the problem is, there is no easily discoverable way for 
the user to force the upgrade. They'll need to hunt the docs for how to 
do that.

> (
>    Although I can understand that, in the _specific_ context of an LSP
>    client that is in active development & "competing" with a MELPA-only
>    alternative, it is a bit of a bummer that M-x package-install 𝒫 will
>    yield something that users might consider "inferior" feature-wise when
>    𝒫=eglot.  A bit of a bummer, but not a deal-breaker IMO; as long as
>    "M-x package-list U x" brings the latest & greatest, I still think
>    package-install's behaviour change re. eglot in Emacs 29 is
>    defensible.
> )

'M-x package-list U x' does not upgrade built-in Eglot either, AFAIU.