Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change.

[Dmitry Gutov <dmitry@gutov.dev>]

On 06/05/2023 18:44, Eli Zaretskii wrote:
>> Date: Sat, 6 May 2023 18:26:11 +0300
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>> One more time: in Emacs 28 package-install doesn't upgrade,
>>>> but it installs the latest, which is incompatible behaviour
>>>> if you move to Emacs 29, where that won't happen.
>>>
>>> Is this for Eglot (and use-package), or is this for any package
>>> installed from ELPA?  IOW, does Emacs 29's package-install still
>>> install the latest version of a package from ELPA?  And does that
>>> happen even if some older version of a package is already installed?
>>
>> Like Joao said:
>>
>>     Yes to the first, no to the second.
> 
> Yes, except that I asked 3 questions, not 2, and the first was "either
> or", so saying "yes" doesn't help.  But never mind.

The answers were for the two questions after "IOW".

>> Meaning, 'M-x package-install' will install the latest version (or some
>> available version) from ELPA, if the package is not installed.
>>
>> If some version of it is installed from ELPA (!) already, 'M-x
>> package-install' won't upgrade.
> 
> Then I don't understand why you decided to drop the similar change to
> package-upgrade.  At the time I thought package-install can be used as
> an alternative, but if it cannot, I think we should add to
> package-upgrade the same optional behavior of upgrading a built-in
> package as we have in package-install.

We now have a better solution on master: 'M-x package-upgrade' simply 
upgrades the built-ins, no questions asked.

If we added the behavior similar to the addition in package-install 
(with prefix arguments and guarded by an option, possibly even a new 
optional argument), we'd have to carry over that awkward convention to 
Emacs 30 in some form. And as you recall, Joao wasn't happy with either 
solution anyway (of those that you liked enough).

> What other methods currently exist to upgrade an already installed
> package (or a non-built-in package that is already installed)?  I know
> about one -- via lisp-packages (a.k.a. package menu); are there
> others?

Also:
M-x package-upgrade
M-x package-upgrade-all

> Will any of these methods upgrade a built-in package, at least as an
> optional behavior?

Not in Emacs 29.

>>>> So if you're used to setting up a brand new Emacs 28 and
>>>> package-install Eglot to get versions with nice features and
>>>> bugfixes, you may be dismayed to find that doing the very
>>>> same thing in Emacs 29 results in what will probably be a
>>>> old version.
>>>
>>> Are you talking about users who didn't update their Eglot, except when
>>> a new Emacs version was released?  Or are you talking about users who
>>> updated Eglot from ELPA (using package-install) even between Emacs
>>> releases?  Or are you talking about something else entirely?
>>
>> He is mostly talking about users who e.g. wiped their config directory
>> and ~/.emacs.d/elpa and are starting anew. Or just deleted
>> ~/.emacs.d/elpa/eglot-xxxxxx.
> 
> Is this what many users do?  I'd be surprised, but maybe I'm missing
> something.

I have no idea. Joao says this is common enough. That has not been my 
experience, but I don't deal with support for Eglot users either.

>> In that situation, indeed, 'M-x
>> package-install' will install the latest version from ELPA.
>>
>> In Emacs 29, however, it won't. Because one version of Eglot is
>> available already (built-in).
> 
> But if emptying ~/.emacs.d/elpa is not a frequent use case, why should
> we care about it so much?  It sounds like bug#62720 and the entire
> long dispute that followed were focused on this strange use pattern,
> instead of talking about more reasonable upgrade scenarios?

We focused on it because, apparently, using 'M-x package-install' worked 
in more cases in Emacs 28 than in Emacs 29. And some think it's 
important. And because 'package-upgrade' is not in Emacs 28 at all.

Personally, I think it's better to focus on fixing 'package-upgrade' 
(which I did). But I don't think it's constructive to hide that fix 
behind a pref.

>> I'm pretty sure I have outlined this twice already, not too long ago.
>> Prefacing the first message with an apology, saying I had been
>> previously confused myself.
> 
> I apologize for being confused and for asking almost the same
> questions repeatedly, but given that fact that even people who are
> familiar with package.el are confused, I think I'm in good company.

It's okay. Just answering the question from your second response in this 
thread.