bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kévin Le Gouguec
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Sat, 15 Apr 2023 23:16:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

João Távora <joaotavora@gmail.com> writes:

>>   between Eli & Philip re. changing package-install or package-update
>>   makes me unsure what "U x" will actually do with eglot in Emacs 29, so
>>   my previous parenthesized digression might be moot.
>
> Alas U x in the package menu _also_ doesn't upgrade Eglot.  And neither
> does M-x package-update-all.  I don't see any plans for doing so.

Interesting; thank you and Dmitry for confirming my impression.

This was perhaps the most surprising aspect of the equation IMO,
although now it does not sound so bad since, IIUC from reading
package.el, _once_ users manage to install eglot from ELPA (using
Philip's pending user option), _then_ either method should let them
fetch future upgrades transparently.

(
  Took me a couple of minutes to reach that conclusion; found it mildly
  confusing that package-update-all and package-menu-mark-upgrades each
  have their own heuristics for enumerating candidates.  IIUC the former
  iterates through package-alist; the latter looks at all *Packages*
  lines with status ∈ '("installed" "dependency" "unsigned" "external").

  So once eglot becomes "installed" under package-user-dir, both methods
  should allow users to stay on top of new versions… ?

  Hope that's not my optimism skewing my reading of the code.
)

(
  Neither here nor there, but this whole discussion reminds me of
  bug#59005, where another :core package (transient) gets silently
  updated from ELPA if it's a dependency of a package that the user asks
  to install (magit).  Assuming (a) I correctly understand what that
  other bug report is about (b) I correctly understand what Philip's
  patch does, ISTM that it will cause a behaviour change in that
  situation too?

  Not wholly sure about (a) nor (b) though, and even then, not wholly
  sure that the change would be for the worse, especially since there
  would now be a user option to make the desired behaviour explicit.
)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]