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

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Done

> (Unless you also want to revert on master, don't forget to say "do not
> merge" in the log message.)

No, it doesn't make sense to keep the current change on master either.

> Thanks.