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

[Dmitry Gutov]

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.

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