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

[Dmitry Gutov <dmitry@gutov.dev>]

On 07/05/2023 08:51, Eli Zaretskii wrote:
>> Date: Sat, 6 May 2023 23:31:31 +0300
>> Cc: philipk@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 06/05/2023 22:38, Eli Zaretskii wrote:
>>>> package-menu-mark-upgrades ('U') is not affected by
>>>> package-install-upgrade-built-in. It won't.
>>>
>>> Shouldn't it?
>>
>> Maybe, maybe not.
> 
> I think it better did, because using "U" would upgrade Eglot and
> use-package in Emacs 28 and before.  So we should give users who want
> that the capability of keeping that workflow in Emacs 29, if only as
> opt-in behavior.
> 
> Also, "/ u" should ideally show built-in packages as well, when
> package-install-upgrade-built-in is non-nil.

So we think upgrading built-in packages could be dangerous, but if the 
user wants to upgrade Eglot, then upgrading all built-ins is suddenly fine?

> Philip, can these two changes be implemented safely for Emacs 29?
> 
>> A user that customized that option to have (package-install 'eglot)
>> ensure that a version from ELPA is installed might not want or expect
>> for it to affect package-menu-mark-upgrades and/or package-upgrade-all.
> 
> That is true, but denying them the possibility of upgrading would be
> worse, I think.  And since this is opt-in behavior, the user is less
> likely to be tripped by that without realizing it.
> 
>> Or anticipate the full consequences anyway.
> 
> Documentation should solve this aspect.

If the only way to get a basic scenario to work is to toggle a pref, we 
won't be able to go back and say "you shouldn't have toggled it".

If we don't actually consider upgrading of all built-ins to be a 
problem, and are just hesitant to enable it in Emacs 29, then I guess it 
is fine.

Otherwise, we've had a pretty good idea posted previously: patch where a 
variable holds the list of builtins that should be upgraded automatically.