bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot


From: Eli Zaretskii
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@debbugs.gnu.org, philipk@posteo.net, larsi@gnus.org,
>  monnier@iro.umontreal.ca, joaotavora@gmail.com
> From: Dmitry Gutov <dmitry@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]