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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org, joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Sat, 22 Apr 2023 14:20:12 +0300

> Date: Sat, 22 Apr 2023 13:48:41 +0300
> Cc: joaotavora <at> gmail.com, jporterbugs <at> gmail.com, 62720 <at> debbugs.gnu.org,
>  philipk <at> posteo.net, monnier <at> iro.umontreal.ca, larsi <at> gnus.org
> From: Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.