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

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

[Boruch Baum]

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.

I'm now left with function package-autoremove reporting:

12 packages will be deleted:
session, muttrc-mode, markdown-toc, htmlize, diminish, dictionary,
debian-el, csv-mode, browse-kill-ring, boxquote, bm, magit-popup,
proceed? (y or n) y

All of which are 'system' packages (at least in debian) so they won't
actually be deleted by my hack, but at least the other ~40 were finally
able to be removed.

I have reservations that this hack is a true and correct solution for
the bug because I don't know enough about the 'package package, but it
does seem to do the job...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

[Lars Ingebrigtsen]

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.

I'm assuming that the package wasn't literally "foo" -- what package was
it that it wanted to remove?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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.

Indeed.  The question is why these packages are considered for removal
at all.

If we can avoid doing that, the error "Package `%s' is used by `%s' as
dependency, not deleting" seems correct to me - it will catch bugs.

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

[Boruch Baum]

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

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

[Boruch Baum]

On 2020-10-30 13:34, Stefan Kangas wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > 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.
>
> Indeed.  The question is why these packages are considered for removal
> at all.

The function that builds the candidate list, package--removable-packages,
doesn't take into account the criteria used in function 'package-delete'.

> If we can avoid doing that, the error "Package `%s' is used by `%s' as
> dependency, not deleting" seems correct to me - it will catch bugs.

That's not really my point. My point in the bug report is that while
technically the use of function 'error' is correct in this case, it works
out to be counter-productive and should be replaced with a simple use of
the function 'message' logging the condition to the *Messages* buffer.
Using the error function aborts the entire auro-remove process for all
packages on the list, and in this case isn't even useful for the specific
package because the function is written to independently reject further
processing for the package.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> 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

Please submit this bug, including which version(s) you are seeing this
on, as a separate bug report.

Thanks in advance.

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

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> That's not really my point. My point in the bug report is that while
> technically the use of function 'error' is correct in this case, it works
> out to be counter-productive and should be replaced with a simple use of
> the function 'message' logging the condition to the *Messages* buffer.

Since it sounds like package-autoremove is making a list of candidates
that includes packages that should not be removed, the `error' there
sounds like exactly the right thing?  Because it's uncovering a bug in
package-autoremove.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Boruch Baum]

On 2020-11-01 13:44, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > That's not really my point. My point in the bug report is that while
> > technically the use of function 'error' is correct in this case, it works
> > out to be counter-productive and should be replaced with a simple use of
> > the function 'message' logging the condition to the *Messages* buffer.
>
> Since it sounds like package-autoremove is making a list of candidates
> that includes packages that should not be removed, the `error' there
> sounds like exactly the right thing?  Because it's uncovering a bug in
> package-autoremove.

But it shouldn't prevent the user from auto-removing all the other
legitimate packages! I had been ignoring this for a long time until the
accumulated list exceeded 40 packages. In the end, this bug denied
removal of 28, which were all removed when I replaced the 'error' with a
'message'. With my approach, users still get the notification of the
problem, and are able to perform the legitimate parts of the operation.

Another way of thinking about the issue it to imagine offering the user
to auto-remove packages individually, selecting one package at a time.
In that imaginary (and burdensome) case would you also deny the user to
remove package F because some other package B was improperly on some
list?

Yet another way of thinking about the issue is to think of the
consequences. In this case, the error function isn't stopping anything
bad from happening (the system package wouldn't get removed even without
the abort), it only stops other good things from happening (legitimate
packages don't get removed).

If you absolutely insist on using the 'error' function, you can delay it
until processing *all* the packages, accumulating the names of the system
ones. That approach will also generate a more informative error message
than is currently done because it could report all the packages
wrongfully on the list (currently, only the first is reported).


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0