|
From: | Dmitry Gutov |
Subject: | bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot |
Date: | Sun, 23 Apr 2023 23:56:23 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
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?
[Prev in Thread] | Current Thread | [Next in Thread] |