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

[Dmitry Gutov]

On 14/04/2023 19:28, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> > I would think it's too late in the game to break compatibility.
> > Naming aside package-install has certain behaviour that for a certain
> > set of inputs used to produce predictable things.
> > Now, for the same inputs it does nothing on Emacs 29.
>
> The only way I can think of to preserve compatibility is to change the
> behavior so it doesn't pay attention to "is builtin or not" but to "used
> to be builtin before Emacs-29".  This would make a bad semantics even
> worse, so I'd rather we fix the semantics to something clean.

We could add a new attribute/package header which would mean "eagerly 
upgradable [even when] built-in".

> > I think it should do the same thing, not only because it's
> > nicer for the unsuspecting user, but also because trying to
> > protect this user from "unintentional" upgrade of certain "unstable"
> > packages, as it seems to be the idea here, is a losing game
> > anyway, just because dependencies.
>
> You may be right: maybe the distinction between "install only" and
> "install&upgrade" isn't worth the trouble.
>
> I think to get closer to a useful "install only" behavior we'd want that
> command to prompt the user before upgrading dependencies (tho probably
> only for those in `package-selected-packages`).
>
> BTW, for me the reluctance to upgrade when asked to install isn't due to
> the risk that the package is "unstable".  I'm not completely sure what
> is the reason, admittedly, but it's closer to viewing it as a silent
> "change of distribution",

That's my feeling too.

> or maybe it's because I like to know when
behavior may change and merely installing a package shouldn't change
Emacs's behavior.

This is probably a different question: whether 'M-x package-install' 
should do upgrades at all, whether the package is built-in or not.