[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44306: package-delete exiting on encountering system/dependency pack
From: |
Boruch Baum |
Subject: |
bug#44306: package-delete exiting on encountering system/dependency packages |
Date: |
Sat, 31 Oct 2020 22:35:00 -0400 |
User-agent: |
NeoMutt/20180716 |
On 2020-10-30 14:12, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > When attempting to perform package-autoremove to clean up obsolete
> > packages, my emacs would abort with an error that `foo' is a system
> > package. Thus, it had become impossible to perform the operation. I
> > altered function package-delete to replace its two calls to function
> > `error' with simple `message' and can now clean up the packages.
>
> It kinda sounds like there something wrong in what package-autoremove is
> trying to delete.
Exactly the point.
> I'm assuming that the package wasn't literally "foo" -- what package was
> it that it wanted to remove?
'session', the first item on the remaining list that I included. In my
case, each of those 12 packages is described as a 'system' package.
As a follow-up, I'm now noticing an additional related bug, which is
kind-of a resiliency issue. Let's say several versions of a package
accumulate, then what has happened in my case is that package-autoremove
only deletes the single most recent obsolete version. For example, in
examining my *Messages* buffer, I see that one run of the function
reported
Package ‘popup-20200610.317’ deleted.
A next run of the function reported
Package ‘popup-20200531.742’ deleted.
Finally, the most recent run of the function reported:
Package ‘popup-0.5.8’ is a system package, not deleting
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0