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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 25 Apr 2023 02:45:46 +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>
> 
> >> 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's this:

  <menu-bar> <package> <Mark All Available Upgrades> runs the command
  package-menu-mark-upgrades (found in package-menu-mode-map), which is
  an interactive byte-compiled Lisp function in ‘package.el’.

  It is bound to U.

  (package-menu-mark-upgrades)

  Mark all upgradable packages in the Package Menu.
  For each installed package with a newer version available, place
  an (I)nstall flag on the available version and a (D)elete flag on
  the installed version.  A subsequent x
  call will upgrade the package.

I also envision that we will at some point have an "upgrade" menu
item, because it make little sense to have this command, but not to be
able to invoke it from the menu.

> There are also no known callers aside from package-update-all.

One caller is enough, IMO.

> 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.

Thanks, this is very close to what I had in mind.  The only thing that
is missing is the support for user option, which should then avoid the
need to invoke the command with a prefix argument.

> Also please review the docstring change.

It looks OK to me.

> 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.

> -(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?