|
From: | Dmitry Gutov |
Subject: | bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot |
Date: | Tue, 25 Apr 2023 21:35:11 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
On 25/04/2023 15:43, Eli Zaretskii wrote:
Date: Tue, 25 Apr 2023 15:08:15 +0300 Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca From: Dmitry Gutov <dmitry@gutov.dev>-(defun package-update (name) - "Update package NAME if a newer version exists." +(defun package-update (name &optional update-built-ins) + "Update package NAME if a newer version exists. + +Only packages installed from ELPA are allowed to be updated this +way.I'm not sure I understand where this restriction comes from. Did the original code enforce it?I'm not sure what you mean about "enforce it". That's the essence of the bug here: this function's inability to upgrade built-in packages (packages installed not from ELPA). Since you are asking to keep that behavior by default, it now needs to be documented.Oh, then I misunderstood what that says. I thought is says ELPA as opposed to, say, MELPA.
No, just ELPA in general.
So I think we need to rephrase that. Something like Packages which are part of the Emacs distribution cannot be updated that way.
This is probably better. As long as we understand it to read "packages which are part ... and were never upgraded to a version from ELPA".
>> Regarding obeying package-install-upgrade-built-in, I think it would >> need to be renamed, and both package-update-all and >> package-menu-mark-upgrades would need to be made obey it too. All that >> could be done in a subsequent change. > > If the option will affect more than just package-install, it should > indeed be renamed. That will require some more work. On package-menu-mark-upgrades in particular. TBH, I'm getting more doubts about this change now. What will we do in Emacs 30? If we add the new argument, it will be hard to back out of it, to default to the proper behavior.I thought that in Emacs 30 we could make the user option be non-nil by default, assuming we will decide not to treat built-in packages specially in this regard. Then the additional argument will become much less important, perhaps for some rare situations or something.
It would remain an odd vestige, and it might be difficult to repurpose for something more useful (e.g. being able to pick a specific version to upgrade/downgrade to?)
Perhaps we should just wait and then fix it on master properly. Workarounds exist, after all.I won't object, but I thought you and others wanted to have package-install and package-update to behave consistently in this respect.
Having package-install and package-update behave the same was never the goal, at least not for me.
Quite the opposite: package-install doesn't install anything when the package is already installed (and the argument is a package name symbol, which is the case for interactive invocations).
package-update/upgrade, OTOH, is supposed to upgrade already installed packages. Which I'm assuming is the category we are going to assign the built-ins to, after all.
[Prev in Thread] | Current Thread | [Next in Thread] |