bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]