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

Previous Next

Full log

Message #245 received at 62720 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: João Távora <joaotavora <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, larsi <at> gnus.org, 62720 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#62720: 29.0.60; Not easy at all to upgrade :core packages
 like Eglot
Date: Wed, 12 Apr 2023 23:50:00 +0300

On 12/04/2023 19:29, João Távora wrote:
> On Wed, Apr 12, 2023 at 4:58 PM Eli Zaretskii<eliz <at> gnu.org>  wrote:
> 
>>>>> Had another idea: what about this very tiny patch, then?  It makes `M-x
>>>>> package-install` work for installing a :core package.  This also rhymes
>>>>> exactly with Stefan's intution/feeling that :core packages need to be
>>>>> "installed" to promote them to installable.  The current M-x
>>>>> package-install recommendation could remain flawlessly and then you can
>>>>> do whatever you think is best for M-x package-update & friends.
>>>> This has the same problem: it modifies a function that is called in
>>>> too many places.  package-installed-p has half a dozen callers in
>>>> package.el alone.  The change is tiny, but what about its
>>>> implications on every use case where it is involved?
>>> What if we only fix 'package-upgrade' (nee package-update) in emacs-29?
>> I believe that's what João was proposing.
> AFAICT, Dmitry was asking only for package-update, not
> package-update-all.  Stefan was also inclined for that.
> 
> In my changes, I changed both.  But it is not hard for me to touch
> only package-update and to do it with the utmost care for
> separation and stability.

I think that would make sense. Like Philip phrased it, updating from a 
bundled version is like switching to a different package repository, 
with different stability expectations.

I also seem to recall some logic somewhere that made sure that the 
package is only updated from the source that it was installed from 
(unless explicitly instructed otherwise by the user). We could treat 
"builtins" as a separate source for that purpose, too.

> For the moment, I'm focusing on M-x package-install, like Philip is.
> There seems to be more consensus there that it should offer to update
> builtin packages that have never been updated.
> 
> I do believe there is high demand for a "upgrade/update" mechanism
> that just "updates whatever there is to update, don't care if core
> or whatnot" and people looking at package-update-all and
> package-menu--mark-upgrades (the "U" command Dmitry brought up)
> will eventually be disappointed.

I think "U" should only update the packages that are either not 
built-in, or the built-ins that have been at least updated once 
(meaning, some "external" version is already installed). For reasons of 
stability, mostly. But using 'M-x package-upgrade' would opt-in 
individual packages into that upgrading mechanism too.

That might not be everyone's cup of tea, so adding a user option like 
'package-upgrade-all-builtins' would work too, allowing the user to opt 
into the more risky behavior.

The semantics of 'package-install' are less clear to me. E.g. it 
wouldn't be out of the question to always error out when the package 
(some version) is already installed. So I could see it being "fixed" 
either way sometime in the future.

Previous Next

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