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

[Dmitry Gutov]

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.