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

Previous Next

Full log

Message #29 received at 74556 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74556 <at> debbugs.gnu.org
Subject: Re: 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 <at> daniel-mendler.de> > 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.

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

Previous Next

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