[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#74556: 30.0.92; Package upgrade can fail and results in deleted pack
From: |
Philip Kaludercic |
Subject: |
bug#74556: 30.0.92; Package upgrade can fail and results in deleted package |
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?
> 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.
Forget it, I didn't think it through.
> Thanks.
>
> Daniel