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

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  joaotavora@gmail.com,
>   62720@debbugs.gnu.org,  larsi@gnus.org
> Date: Wed, 12 Apr 2023 07:44:20 +0000
> 
> >> I'm not sure why, admittedly, but I think it comes down to the fact that
> >> the first upgrade of a `:core` package from GNU ELPA feels to me more
> >> like an "install" than an "upgrade".
> >
> > Which means my proposal of adding a new command
> > package-update-core-package makes more and more sense: 
> 
> I am not sure that "core package" is necessarily a term or concept that
> users would be familiar with.  Or at least I have seen users confused
> about the concept online, not realising that a core package can be
> updated via ELPA.

I'm okay with an alternative terminology, like "built-in".

> How about something along the lines of `package-update-from-built-in'?

Not sure about the "from" part.  How about package-update-built-in
instead? or maybe package-upgrade-builtin (since built-in packages
will only ever be upgraded, at least normally)?

> >                                                        we will
> > probably need to handle such packages specially for any number of
> > reasons, more so as we go with our plan to have them only on ELPA and
> > "bundle" them when the release is tarred.  
> 
> Could you elaborate on this plan.  Or perhaps I just lack the background
> to see how these issues are related?

The plan is to provide a command similar to package-update, but which
will be used only for built-in packages which are also on ELPA
(a.k.a. "core packages").  The internals will probably be different,
since package-update offers only non-built-in packages as completion
candidates, the data structures package.el uses for built-in and
non-built-in packages are different, and installing an updated package
should NOT delete the bundled one, just install the newer version so
that it is used in preference to the bundled one.  Other than that,
the UI is supposed to be the same as in package-update.

If something else is unclear, please ask.

> >                                            So having such a command
> > now will be a good investment for the future.
> >
> > Philip, if this makes sense, would you please add such a command on
> > the emacs-29 branch?  If the exact purpose and effects of the command
> > are not clear yet, let's talk about it and finalize that.
> 
> Can do.  This would prompt the user for a core package that hasn't been
> installed from ELPA yet, and would make sure the package instead of the
> core code is loaded?

Yes.  But when you say "hasn't been installed from ELPA yet", do you
mean that once it has been installed, users will have to use a
different command for updating it further?  That might be confusing;
I'd prefer that the same command is used for all the updates of
built-in packages.  For example, if we'd later want to support
downgrading back to the bundled version, the implementation will be
different for built-in packages, so having a separate command will
save us some maintenance headaches.

> If there is no difference in version between the ELPA and the core
> package, should we say anything?

Probably just user-error, I guess?  Or maybe optionally provide a way
of forcing the update, like if the user wants to reinstall the package
anyway for whatever reasons?

Thanks.