On 24/04/2023 14:58, Eli Zaretskii wrote: >> Date: Mon, 24 Apr 2023 00:53:30 +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 >> >> On 23/04/2023 17:24, Eli Zaretskii wrote: >>>> Date: Sun, 23 Apr 2023 16:11:44 +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 >>>> >>>>>> It addressed two last points from your previous email, obviously. >>>>> Which points are those? Please help me identify them. >>>> >>>> These two: >>>> >>>> > There is already such an option, added as part of fixing this bug. >>>> >>>> The binding was added, so now we straight away delegate to package-install. >>> >>> I meant to give the user the control on whether package-update will >>> update built-in packages, like we did with package-install: either via >>> prefix argument or by customizing the user option. >> >> That would be a different change, though. >> >> So what are we guarding against here? That the user will choose a >> built-in package to upgrade by accident? > > Yes. Also, against invocations of this command from other commands > and from the menu. It's not in the menu. There are also no known callers aside from package-update-all. >> And we'll show her an error, saying "use the prefix argument"? > > No, I think we'll do whatever the code does today when passed a > built-in package. Very well, here's the next version. It adds a new optional argument to the function (so that people can evaluate e.g. (package-update 'eglot t)). When called interactively, it is determined by current-prefix-argument. Also please review the docstring change. 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.