GNU bug report logs - #74556
30.0.92; Package upgrade can fail and results in deleted package

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74556 <at> debbugs.gnu.org
Subject: bug#74556: 30.0.92; Package upgrade can fail and results in deleted package
Date: Tue, 10 Dec 2024 21:24:35 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>>> Cc: 74556 <at> debbugs.gnu.org
>>>>> From: Philip Kaludercic <philipk <at> posteo.net>
>>>>> Date: Thu, 28 Nov 2024 11:34:51 +0000
>>>>> 
>>>>> Philip Kaludercic <philipk <at> 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.

I don't understand how the code you proposed works. It seems that after
the deletion, if the installation fails, the package will stay deleted?
Anyway, no hurry from my side to get this fixed.

Thanks.

Daniel

Previous Next

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