|
From: | Dmitry Gutov |
Subject: | bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot |
Date: | Sat, 22 Apr 2023 13:30:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
On 22/04/2023 11:33, Eli Zaretskii wrote:
Date: Sat, 22 Apr 2023 03:57:03 +0300 From: Dmitry Gutov<dmitry@gutov.dev> Cc:jporterbugs@gmail.com,philipk@posteo.net,62720@debbugs.gnu.org, joaotavora@gmail.com,larsi@gnus.org,monnier@iro.umontreal.caThat's what I imagined: adding a new optional argument to package--updateable-packages which would include builtins in the result. And only pass it when called from package-upgrade. Hopefully that's the kind of optional that you meant.Here's a patch which does that. The diff could be reduced (the package-update part) by binding the new option (package-install-upgrade-built-in), but I figured it's better to avoid interdependency while we're still deciding what to keep.Thanks, but this is not what was being discussed, AFAIU. What I said I'd agree to is to have package-update accept a prefix argument and heed package-install-upgrade-built-in (perhaps renamed),
I think I explained in the previous email why reusing package-install-upgrade-built-in doesn't seem like a good idea.
and only then update built-in packages.
I asked what plausible scenario you think might be broken by having package-update upgrade builtin package by default.
Do you want to answer that?
I also don't think I like the significant changes in package-update, nor understand why they are needed.
Like I said: the changes are to avoid relying on package-install being able to install a package that's already installed. Which currently works only for builtins and when only a user option is set. It's a mess.
And to "avoid interdependency". Just to be clear, we are talking about the 4 lines at the end, right?
[Prev in Thread] | Current Thread | [Next in Thread] |