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

Previous Next

Full log

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

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: Re: bug#62720: 29.0.60; Not easy at all to upgrade :core packages
 like Eglot
Date: Sat, 22 Apr 2023 14:24:47 +0300

On 22/04/2023 14:11, Eli Zaretskii wrote:
>> Date: Sat, 22 Apr 2023 13:30:41 +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>
>>
>>> Thanks, but this is not what was being discussed, AFAIU.  What I said
>>> I'd agree to is to have package-update accept a prefix argument and
>>> heed package-install-upgrade-built-in (perhaps renamed),
>>
>> I think I explained in the previous email why reusing
>> package-install-upgrade-built-in doesn't seem like a good idea.
> 
> And I thought I've explained why I didn't see a need for another
> option.

I also don't see the point of using an option here.

Also think forward to Emacs 30: I think the most reasonable choice would 
be to have package-update upgrade builtins by default, whereas 
package-update-all and package-menu-mark-for-upgrades probably still 
need to be preffed off (not sure, but we won't be able to make the 
choice until later, I think).

But if to make package-update behave properly we need to flip the 
default of the said option, it will flip the behavior of 
package-update-all and package-menu-mark-for-upgrades as well.

>>> and only then
>>> update built-in packages.
>>
>> I asked what plausible scenario you think might be broken by having
>> package-update upgrade builtin package by default.
> 
> That's obvious: this is how package-update behaved until now.

That's not an answer to the question.

>>> I also don't think I like the significant changes in package-update,
>>> nor understand why they are needed.
>>
>> Like I said: the changes are to avoid relying on package-install being
>> able to install a package that's already installed. Which currently
>> works only for builtins and when only a user option is set. It's a mess.
>>
>> And to "avoid interdependency".
> 
> Why does this have to be in Emacs 29?  It's a cleanup, right?

Not a cleanup, no. If I just keep the previous version of the code, I 
get "package xxx is already installed". Because when upgrading a builtin 
package, the "current" version is not deleted.

So we need to compute the exact version to install (then package-install 
does not say "it's already installed" because the installed version is 
different). The use of package-install-from-archive might have been a 
mistake, though, (in case dependencies need to be updated too) I'm 
looking into that now.

Alternatively, we could add an optional argument to package-install 
which would mean "install the latest version anyway".

>> Just to be clear, we are talking about the 4 lines at the end, right?
> 
> Yes, and also the (somewhat mysterious) additions of tests for
> pkg-desc.

pkg-desc is nil for builtin packages in this case (they are not in 
package-alist, so (assq package package-alist) returns nil).

Previous Next

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