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

Previous Next

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 21:35:11 +0300

On 25/04/2023 15:43, Eli Zaretskii wrote:
>> Date: Tue, 25 Apr 2023 15:08:15 +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>
>>
>>>> -(defun package-update (name)
>>>> -  "Update package NAME if a newer version exists."
>>>> +(defun package-update (name &optional update-built-ins)
>>>> +  "Update package NAME if a newer version exists.
>>>> +
>>>> +Only packages installed from ELPA are allowed to be updated this
>>>> +way.
>>>
>>> I'm not sure I understand where this restriction comes from.  Did the
>>> original code enforce it?
>>
>> I'm not sure what you mean about "enforce it". That's the essence of the
>> bug here: this function's inability to upgrade built-in packages
>> (packages installed not from ELPA). Since you are asking to keep that
>> behavior by default, it now needs to be documented.
> 
> Oh, then I misunderstood what that says.  I thought is says ELPA as
> opposed to, say, MELPA.

No, just ELPA in general.

> So I think we need to rephrase that.  Something like
> 
>    Packages which are part of the Emacs distribution cannot be updated
>    that way.

This is probably better. As long as we understand it to read "packages 
which are part ... and were never upgraded to a version from ELPA".

>>   >> 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.
>>   >
>>   > If the option will affect more than just package-install, it should
>>   > indeed be renamed.
>>
>> That will require some more work. On package-menu-mark-upgrades in
>> particular.
>>
>> TBH, I'm getting more doubts about this change now.
>>
>> What will we do in Emacs 30? If we add the new argument, it will be hard
>> to back out of it, to default to the proper behavior.
> 
> I thought that in Emacs 30 we could make the user option be non-nil by
> default, assuming we will decide not to treat built-in packages
> specially in this regard.  Then the additional argument will become
> much less important, perhaps for some rare situations or something.

It would remain an odd vestige, and it might be difficult to repurpose 
for something more useful (e.g. being able to pick a specific version to 
upgrade/downgrade to?)

>> Perhaps we should just wait and then fix it on master properly.
>> Workarounds exist, after all.
> 
> I won't object, but I thought you and others wanted to have
> package-install and package-update to behave consistently in this
> respect.

Having package-install and package-update behave the same was never the 
goal, at least not for me.

Quite the opposite: package-install doesn't install anything when the 
package is already installed (and the argument is a package name symbol, 
which is the case for interactive invocations).

package-update/upgrade, OTOH, is supposed to upgrade already installed 
packages. Which I'm assuming is the category we are going to assign the 
built-ins to, after all.

Previous Next

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