bug#74556: 30.0.92; Package upgrade can fail and results in deleted package

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  74556@debbugs.gnu.org
> Date: Tue, 10 Dec 2024 20:31:59 +0000
> 
> Daniel Mendler <mail@daniel-mendler.de> > Philip Kaludercic 
> <philipk@posteo.net> writes:
> >
> >> Daniel Mendler <mail@daniel-mendler.de> writes:
> >>
> >>> Philip Kaludercic <philipk@posteo.net> writes:
> >>>
> >>>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>>
> >>>>>> Cc: 74556@debbugs.gnu.org
> >>>>>> From: Philip Kaludercic <philipk@posteo.net>
> >>>>>> Date: Thu, 28 Nov 2024 11:34:51 +0000
> >>>>>> 
> >>>>>> Philip Kaludercic <philipk@posteo.net> writes:
> >>>>>> 
> >>>>>> [...]
> >>>>>> 
> >>>>>> > It might make sense to try and "deactivate" a package before 
> >>>>>> > installing
> >>>>>> > the new package.  Looking into some second-try fallback for
> >>>>>> > package-install to refresh the package index if a package was not 
> >>>>>> > found
> >>>>>> > would also be a good idea ^^
> >>>>>> 
> >>>>>> This might do it?
> >>>>>
> >>>>> Philip, please install this on the emacs-30 branch, unless you see any
> >>>>> problems with the change.  We'd like to make another pretest soon.
> >>>>
> >>>> Done.  But we should keep the report open as there might be better
> >>>> approaches to discuss in the future.
> >>>
> >>> Hello Philip,
> >>>
> >>> I just tried the modified `package-upgrade' function and it doesn't seem
> >>> to work. It seems to break the upgrade procedure in an even worse way,
> >>> at least in my setup. Now `package-install' is tried first with the
> >>> package symbol, which will be a no-op, since the package is already
> >>> installed. Afterwards the package is deleted and we always end up with
> >>> no package. Probably `package-install' should also be called with a
> >>> package descriptor of the new package version?
> >>
> >> Right, my sincere apologies for that oversight.  That being said, I
> >> don't feel comfortable fixing this right now as I am short on time to
> >> fix and test something like this on the "emacs-30" branch.  My vote
> >> would be to revert the commit and try to tackle the issue on the
> >> "master" branch.  An alternative I can propose that would be closer to
> >> the original code might be
> >
> > Yes, I also vote to revert your commit on the emacs-30 release branch.
> > The issue isn't severe (and not a regression), so I'd say it is okay to
> > fix the issue on the master branch.
> 
> Eli, what do you say?

It looks like you are in agreement, so please revert on emacs-30.
(Unless you also want to revert on master, don't forget to say "do not
merge" in the log message.)

Thanks.