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

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 23/04/2023 16:02, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> 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.

I will look into this.

>>> 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"?

Respect `package-archive-priorities'.

>> 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.

Oh, I did not know it was on MELPA in the first place.  I haven't been
using the archive for a while.

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

Hmm, I guess that is true, but I have never been a fan of advertising
the -devel archives for day-to-day usage.

>> 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?

At any place where (cadr ...) is used, I would assume.