bug#44306: package-delete exiting on encountering system/dependency packages

[Boruch Baum <boruch_baum@gmx.com>]

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