GNU bug report logs -
#62720
29.0.60; Not easy at all to upgrade :core packages like Eglot
Previous Next
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 #610 received at 62720 <at> debbugs.gnu.org (full text, mbox):
On 20/04/2023 13:02, Eli Zaretskii wrote:
>> Date: Thu, 20 Apr 2023 01:06:10 +0300
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, arne_bab <at> web.de, jporterbugs <at> gmail.com,
>> emacs-devel <emacs-devel <at> gnu.org>
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> OK then, I think have to re-evaluate my position on this. Previously, I
>> guess, I made some hasty conclusions from how the discussion went on
>> without refreshing the exact details about package.el and use-package
>> (the latter I never knew to begin with). Apologies.
>>
>> Eli, let me know if we should take this back to the bug tracker instead.
>
> I've moved this back to the bug-tracker. Please post all further
> replies about this particular issue, i.e. updating of built-in
> packages with package.el, to this bug and not to emacs-devel.
Noted.
>> So I would suggest to focus on functions that don't work as intended.
>> Namely:
>>
>> - Add a user option for the list of builtin packages which would be
>> upgraded automatically by 'package-menu-mark-upgrades' and 'M-x
>> package-upgrade-all' (nee package-update-all). Maybe make it nil by
>> default, or maybe add 'eglot' to it. I don't have a strong opinion.
>>
>> - Fix 'M-x package-upgrade' (nee package-update) to suggest Eglot as one
>> of the options and actually perform the upgrade. That shouldn't require
>> changes to 'package-install' because, as we already know, the user can
>> already install a newer version of Eglot using the 'list-packages' menu
>> (and picking the exact version manually). That execution path is going
>> to go through 'package-install' as well, so it must be suitable already.
>>
>> - Revert 580d8278c5f48 because it creates odd semantics (upgrading
>> certain packages that are already installed but not others) and it
>> doesn't solve the issue with (use-package 'eglot :ensure t) anyway. We
>> could keep it, but seems like a half-measure that didn't make anyone
>> happy anyway. OTOH, it could minimize the rewrites of CI scripts.
>
> I don't think we are ready to make any new decisions in this matter.
> I think we don't even have a comprehensive and detailed picture of the
> problems with updating/upgrading built-in packages in Emacs 29.
> People are still discovering facts and subtleties of various
> package.el commands and features, and are still arguing what exactly
> happens in this or that scenario.
True.
> So before we discuss solutions, we need a full and detailed
> description of the problems to solve. If someone can do the footwork
> of collecting this information and posting it here, please do, and
> TIA.
I think I have made a fair attempt at this, though. Here's an update:
- package-upgrade (nee package-update) doesn't upgrade builtin packages
that never been upgraded before. It's a bug. Hopefully not too hard to fix.
- package-menu-mark-upgrades and package-update-all don't upgrade them
either. That's not necessarily a bug, but a problem nevertheless. A new
user option could help.
- Fixing package-update should also obviate the need for eglot-update.
Though perhaps the latter could still be useful as a single entry point
to recommend to both users of Emacs 28 and 29+.
- The current fix (commit 580d8278c5f48) is not comprehensive WRT to
Joao's scenario because use-package-ensure-elpa short-circuits when it
find that the package is installed ('package-installed-p' returns t). So
(use-package eglot :ensure t) does not upgrade Eglot even when
package-install-upgrade-built-in is t.
- package-install-upgrade-built-in is not nuanced: if we suggest the
users to set it to t, that can result in making _all_ builtin packages
upgradable with 'package-install'. Whereas I think we originally only
wanted that for Eglot and maybe for use-package. For this and other
minor reasons I would suggest reverting 580d8278c5f48. But I suppose we
could also try to make it more granular (e.g. turn the boolean option
into a list). I'm not sure it's a good direction overall, however.
- According to Jim P., package pinning doesn't work for builtin packages
either. Which could be a decent solution as well, e.g. putting something
like this in the docs: (use-package eglot :ensure t :pin gnu) if the
users want the Eglot version from ELPA -- and this form might even be
compatible with Emacs 28. I'm not sure how difficult it would be to fix
package pinning, however.
I haven't spent as much time on this bug as some others here, though, so
corrections and additions are welcome.
> I will say up front that, given what I already read here and in the
> related thread on emacs-devel, there seem to be too many
> inconsistencies and dark corners in this, in particular when built-in
> packages are involved. We will probably be unable to solve them in
> time for Emacs 29.1, certainly not all of them. So don't raise your
> expectations too high.
The reasons for me to be hopeful are:
- The functions are propose to fix are "leaves": those that are supposed
to be used interactively, without (many) known callers in-tree. E.g.
fixing package-update-all shouldn't affect some other part of Emacs as
much as changing package-install could.
- I imagine the diffs will be rather short. I haven't tried to take a
stab at this yet, though, and if somebody wants to take the initiative,
they're very welcome.
The reasons for me to be less hopeful:
- We seem to be unable to come to any agreement here. :-D
Joao's approval for the above list would go a long way.
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.