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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 62720 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com
Subject: Re: bug#62720: 29.0.60; Not easy at all to upgrade :core packages
 like Eglot
Date: Sun, 23 Apr 2023 23:56:23 +0300

On 23/04/2023 16:02, Philip Kaludercic wrote:
> Dmitry Gutov <dmitry <at> 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?

Previous Next

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