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

Previous Next

Package: emacs;

Reported by: João Távora <joaotavora <at> gmail.com>

Date: Fri, 7 Apr 2023 22:11:01 UTC

Severity: normal

Found in version 29.0.60

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #464 received at 62720 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>,
 João Távora <joaotavora <at> gmail.com>
Cc: philipk <at> posteo.net, rpluim <at> gmail.com, 62720 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, larsi <at> gnus.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#62720: 29.0.60; Not easy at all to upgrade :core packages
 like Eglot
Date: Sat, 15 Apr 2023 15:33:44 +0300
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.




This bug report was last modified 2 years and 17 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.