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


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, joaotavora <at> gmail.com
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Tue, 25 Apr 2023 02:45:46 +0300
[Message part 1 (text/plain, inline)]
On 24/04/2023 14:58, Eli Zaretskii wrote:
>> Date: Mon, 24 Apr 2023 00:53:30 +0300
>> Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org,
>>   joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> On 23/04/2023 17:24, Eli Zaretskii wrote:
>>>> Date: Sun, 23 Apr 2023 16:11:44 +0300
>>>> Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org,
>>>>    joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
>>>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>>>
>>>>>> It addressed two last points from your previous email, obviously.
>>>>> Which points are those?  Please help me identify them.
>>>>
>>>> These two:
>>>>
>>>>    > There is already such an option, added as part of fixing this bug.
>>>>
>>>> The binding was added, so now we straight away delegate to package-install.
>>>
>>> I meant to give the user the control on whether package-update will
>>> update built-in packages, like we did with package-install: either via
>>> prefix argument or by customizing the user option.
>>
>> That would be a different change, though.
>>
>> So what are we guarding against here? That the user will choose a
>> built-in package to upgrade by accident?
> 
> Yes.  Also, against invocations of this command from other commands
> and from the menu.

It's not in the menu. There are also no known callers aside from 
package-update-all.

>> And we'll show her an error, saying "use the prefix argument"?
> 
> No, I think we'll do whatever the code does today when passed a
> built-in package.

Very well, here's the next version. It adds a new optional argument to 
the function (so that people can evaluate e.g. (package-update 'eglot 
t)). When called interactively, it is determined by current-prefix-argument.

Also please review the docstring change.

Regarding obeying package-install-upgrade-built-in, I think it would 
need to be renamed, and both package-update-all and 
package-menu-mark-upgrades would need to be made obey it too. All that 
could be done in a subsequent change.
[package-update-fix.diff (text/x-patch, attachment)]

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.