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: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, larsi <at> gnus.org, joaotavora <at> gmail.com
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Sat, 22 Apr 2023 15:00:29 +0300

> Date: Sat, 22 Apr 2023 14:24:47 +0300
> Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org,
>  joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 22/04/2023 14:11, Eli Zaretskii wrote:
> >> Date: Sat, 22 Apr 2023 13:30:41 +0300
> >> Cc: jporterbugs <at> gmail.com, philipk <at> posteo.net, 62720 <at> debbugs.gnu.org,
> >>   joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
> >> From: Dmitry Gutov <dmitry <at> gutov.dev>
> >>
> >>> Thanks, but this is not what was being discussed, AFAIU.  What I said
> >>> I'd agree to is to have package-update accept a prefix argument and
> >>> heed package-install-upgrade-built-in (perhaps renamed),
> >>
> >> I think I explained in the previous email why reusing
> >> package-install-upgrade-built-in doesn't seem like a good idea.
> > 
> > And I thought I've explained why I didn't see a need for another
> > option.
> 
> I also don't see the point of using an option here.

We must not change past behavior unconditionally and by default, not
this close to the release.

> Also think forward to Emacs 30: I think the most reasonable choice would 
> be to have package-update upgrade builtins by default, whereas 
> package-update-all and package-menu-mark-for-upgrades probably still 
> need to be preffed off (not sure, but we won't be able to make the 
> choice until later, I think).

I don't see why package-update and package-update-all should behave
differently wrt core packages.  If the user expresses his/her will to
update core packages, then package-update-all should do this for all
of them.

> But if to make package-update behave properly we need to flip the 
> default of the said option, it will flip the behavior of 
> package-update-all and package-menu-mark-for-upgrades as well.

Which is how it should be, IMO.

> >>> and only then
> >>> update built-in packages.
> >>
> >> I asked what plausible scenario you think might be broken by having
> >> package-update upgrade builtin package by default.
> > 
> > That's obvious: this is how package-update behaved until now.
> 
> That's not an answer to the question.

It is for me (and I'm quite surprised that it is not for you).

> >>> I also don't think I like the significant changes in package-update,
> >>> nor understand why they are needed.
> >>
> >> Like I said: the changes are to avoid relying on package-install being
> >> able to install a package that's already installed. Which currently
> >> works only for builtins and when only a user option is set. It's a mess.
> >>
> >> And to "avoid interdependency".
> > 
> > Why does this have to be in Emacs 29?  It's a cleanup, right?
> 
> Not a cleanup, no. If I just keep the previous version of the code, I 
> get "package xxx is already installed". Because when upgrading a builtin 
> package, the "current" version is not deleted.
> 
> So we need to compute the exact version to install (then package-install 
> does not say "it's already installed" because the installed version is 
> different). The use of package-install-from-archive might have been a 
> mistake, though, (in case dependencies need to be updated too) I'm 
> looking into that now.

With prefix argument, or when package-update-built-in is non-nil, the
behavior of package-install is different.  So just use this, instead
of changing the code of package-update.

> Alternatively, we could add an optional argument to package-install 
> which would mean "install the latest version anyway".

There is already such an option, added as part of fixing this bug.

> >> Just to be clear, we are talking about the 4 lines at the end, right?
> > 
> > Yes, and also the (somewhat mysterious) additions of tests for
> > pkg-desc.
> 
> pkg-desc is nil for builtin packages in this case (they are not in 
> package-alist, so (assq package package-alist) returns nil).

This should either be commented, or a variable with a telltale name
added to reflect this subtlety.

Previous Next

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