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: philipk <at> posteo.net, rpluim <at> gmail.com, 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: Fri, 14 Apr 2023 20:43:16 +0300

> Date: Fri, 14 Apr 2023 19:04:20 +0300
> Cc: 62720 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org,
>  monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 14/04/2023 16:40, Eli Zaretskii wrote:
> >> So on master if I upgrade all packages, ':core' packages would be
> >> automatically upgraded as well?
> > is that what the default of that option means?
> > 
> >> I strongly object to that as a default; just because thereʼs a newer
> >> version on elpa of a :core package doesnʼt mean emacs should upgrade
> >> to it unless*explicitly*  told to do so.
> > I said we_can_  change the default; I didn't say we_must_.  If enough
> > people object to making that the default, it won't be changed.
> 
> We need to have a change in behavior that allows 'M-x package-install' 
> to upgrade built-in packages. But that shouldn't automatically mean that 
> package-menu-mark-upgrades marks all built-in packages for upgrade, or 
> package-upgrade-all (nee package-update-all) does that either.
> 
> We could have another option that enables the latter to upgrade all 
> built-ins too, of course.
> 
> Regarding the currently proposed user option, does it make sense to you 
> to have such option that decides whether package-install upgrades 
> built-ins? Whereas one can always upgrade a built-in package using 'i' 
> (package-menu-mark-install) in the list-packages menu, no matter the 
> value of that option. I get the backward-compatibility intent, but user 
> options should also do something logical from a user's point of view.

All these questions should have been raised and discussed months ago.
Then we could have done the best for the users (what that is, is still
unclear even at this point).  Now it's too late, and the main factor
that will decide how Emacs 29.1 will behave in that regard is whether
the changes to implement that are safe enough to go into Emacs 29.1.

To answer your question more specifically: yes, it does make sense to
me.  The logic, so it seems, is in the eyes of the beholder, and my
eyes do see a certain logic there.

Previous Next

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