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

[Eli Zaretskii]

> Date: Sun, 23 Apr 2023 02:46:05 +0300
> Cc: jporterbugs@gmail.com, philipk@posteo.net, 62720@debbugs.gnu.org,
>  joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dmitry@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.