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

From: Dmitry Gutov <[email-masked]>
Date: Sun, 23 Apr 2023 23:56:23 +0300

On 23/04/2023 16:02, Philip Kaludercic wrote:
> Dmitry Gutov <[email-masked]> writes:
> 
>> Philip,
>>
>> On 13/04/2023 21:49, Philip Kaludercic wrote:
>>> +    (when (and (or current-prefix-arg package-install-upgrade-built-in)
>>> +               (package--active-built-in-p pkg))
>>> +      (setq pkg (cadr (assq name package-archive-contents))))
>>
>> How sure are you that the first element in (cdr (assq name
>> package-archive-contents)) will contain the latest version?
> 
> This is not certain, but the same approach is used in other places in
> package.el, so I just stocked to it.

Perhaps they conceal latent bugs as well. I don't know the codebase too 
well, but the places I did examine used the comparison together with the 
priority.

>> That's why I came with the more complex way to choose the appropriate
>> package-desc in my latest attempt:
>>
>>   (car
>>    (last (seq-sort-by #'package-desc-priority-version
>>                       #'version-list-<
>>                       (cdr (assq package package-archive-contents)))))
> 
> If we insist on package.el installing the newest version, then this
> would make sense.

What's the alternative? Upgrading to "some version"?

> AFAIK there is no guarantees on the order of packages
> in `package-archive-contents'.  This shouldn't be an issue for Eglot,
> but might be one for use-package.

Ah, it seems they removed it from Melpa, that shouldn't surprise me.

Eglot is in the GNU-devel archive as well, though. So there is some 
potential for conflict.

 > I would actually pull it out into a
 > separate utility function that we would re-use in other places.

Since I had to drop the respective code from the latest version of the 
patch, I guess you could put it in package-install instead.

A reusable helper is fine, of course, but what are the other places we 
would use it at?