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: Sun, 23 Apr 2023 09:39:03 +0300

> Date: Sun, 23 Apr 2023 02:46:05 +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>
> 
> >>> 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.
> 
> We're still allowed bugfixing, I believe.

Not when fixing it might introduce another bug or break someone's
workflow.

> >>>>> 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).
> 
> Not sure why you're surprised, you know my approach toward backward 
> compatibility. Never a fan of enshrining problems in amber.
> 
> But in this case it's also a function that's never been in a released 
> Emacs, so the formal conditions are lacking as well.
> 
> And it's okay to use the time since the code was added as a rough proxy 
> for stability, but when it's pretty clear (just from the comments in 
> this very thread) that most people never noticed or forgot that it's 
> there. So it's obviously not very well tested.

What is obvious to you is not obvious to me.

> Just from reading it code and testing, I see another bug: it removes the 
> updated package from package-selected-packages because it doesn't pass 
> NOSAVE to package-delete. Meaning, 'M-x package-autoremove' at any time 
> later will delete it.

If there are bugs, we need to fix them.

Philip, any comments regarding this particular issue with
package-autoremove after 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.
> 
> Ok, since you insist. See attached.

I don't understand how this patch is supposed to be any progress in
this discussion.  I see no prefix argument handling in package-update
and no change in behavior when package-install-upgrade-built-in is
non-nil.  So why did you think this brings the code closer to what I
suggested?

Thanks.

Previous Next

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