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: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: joaotavora <at> gmail.com, larsi <at> gnus.org, 62720 <at> debbugs.gnu.org, philipk <at> posteo.net, 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 19:04:20 +0300

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.

Previous Next

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