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

[Eli Zaretskii]

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

So I think we need to rephrase that.  Something like

  Packages which are part of the Emacs distribution cannot be updated
  that way.

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

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