GNU bug report logs -
#74556
30.0.92; Package upgrade can fail and results in deleted package
Previous Next
Full log
Message #32 received at 74556 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 74556 <at> debbugs.gnu.org
> 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?
It looks like you are in agreement, so please revert on emacs-30.
(Unless you also want to revert on master, don't forget to say "do not
merge" in the log message.)
Thanks.
This bug report was last modified 186 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.