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

[Eli Zaretskii]

> Date: Sat, 22 Apr 2023 13:48:41 +0300
> Cc: joaotavora@gmail.com, jporterbugs@gmail.com, 62720@debbugs.gnu.org,
>  philipk@posteo.net, monnier@iro.umontreal.ca, larsi@gnus.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> The user option I was thinking of would probably be called a little
> >> shorter: package-upgrade-built-in. And it would only affect the upgrader
> >> commands.
> > 
> > We could rename the existing option, if the name is the problem.
> > Otherwise, I don't see why we would need two separate options: they do
> > the same job and have the same meaning from the user's POV.
> 
> The name is a problem, yes. What could also be a problem is a user that 
> customizes this option to have package-update update builtin packages (a 
> reasonable behavior that should be on by default anyway), will also 
> automatically have change the behavior of package-install to be more 
> surprising (install an already installed package).

It's the same change in behavior, since for built-in packages
"install" and "upgrade" is the same.

> Further, if we have a user option affect package-update, we'll have to 
> alter package-update-all and package-manu-mark-for-update in the same 
> patch (otherwise we'll have more nonsense on our hands). Whereas the 
> first version I sent is more minimal.

How is this relevant to whether we need one or two separate user
options?

> >> All this is to say, the first step (upgrading Eglot to the version from
> >> ELPA) will be less user-friendly compared to the other UIs we have. But
> >> it's probably manageable, especially if documented well.
> > 
> > I don't see why it would be less user-friendly.
> 
> The same reason we do have commands with "upgrade" in their names, 
> rather than force everybody to use the "install" and "delete" ones.

I still don't think this is less user-friendly.

> > One again: commit 580d8278c5f48 solved precisely the problem which
> > opened this bug report, nothing more, nothing less.
> 
> It doesn't seem like the originator of the report agrees with that.

I'm aware of that.  But you are talking to me, not to him, and the
above is my opinion.  I also agree that the solution is not ideal,
just the best I could agree to.

> >>    - package-install which will install the latest version of a package,
> >> but only if it's not installed;
> >>    - package-menu-mark-install, which will mark a specific version for
> >> installation, disregarding whether some earlier version is already
> >> installed; the previous version will remain installed still.
> > 
> > Which is again a breaking behavior change, AFAIU.  Is this a good idea
> > so late in the development of Emacs 29?
> 
> The above is not a breaking change, it's how things work already. And 
> have been working for quite a while.

That's not what I understand.  E.g., package-install will install even
if the package is already installed.

But if this already works, then why are you bringing this up?

> >> But even if we decide that we want to eliminate that split, doing *that*
> >> would really be a breaking change. I don't have a reasonable plan to
> >> present for doing that in Emacs 29, so far.
> > 
> > There's no "split".  What I wanted to point out is that we don't seem
> > to have a clear vision of these two commands, since they are confusing
> > intertwined.  In fact, one could argue that package-upgrade in its
> > current form is simply a convenience shortcut for "delete old and
> > install new".
> 
> What should an upgrade command do, in your opinion, if not "delete old 
> and install new"?

Why is this question important, in the context of the current
discussion?  It's a tangent.  All I wanted to point out is that IMO
there's no "split" that we want to eliminate.