When passing a nonexistent or ambiguous package name to `emerge --depclean`, it prints out a message indicating failure, but returns a "successful" execution status. Reproducible: Always Steps to Reproduce: 1. Run `emerge --depclean` on a nonexistent (or ambiguous) package name, and print out the exit code: >$ emerge --depclean foo; echo $? Actual Results: The printed out exit code is 0: >--- Couldn't find 'foo' to depclean. >>>> No packages selected for removal by depclean >0 Expected Results: The command should produce a non-zero exit code: >--- Couldn't find 'foo' to depclean. >>>> No packages selected for removal by depclean >1 `emerge --unmerge` produces a non-zero status in identical conditions: >$ emerge --unmerge foo; echo $? > * This action can remove important packages! In order to be safer, use > * `emerge -pv --depclean <atom>` to check for reverse dependencies before > * removing packages. > >>>> These are the packages that would be unmerged: > >--- Couldn't find 'foo' to unmerge. > >>>> No packages selected for removal by unmerge >1
Please include emerge --info.
Created attachment 874469 [details] emerge --info output
Thanks. I was sure this was nailed down in bug 851750.
Ah, seems bug 851750 was intended more for the "unsuccess" case where something was definitely pulled in to depclean, but not where no package was ever even selected.
Agh, sorry, missed the bug tag: commit b7e35beaa4168b315ad3ae294b71706d24c795b0 Author: John Helmert III <ajak@gentoo.org> Date: Wed Nov 15 19:45:14 2023 -0800 depclean: return failure when no packages are selected for depclean Based on the preceding writemsg, one might think that this function could be used for more than depcleans, but there's no other reference to it in the codebase. With this patch: $ sudo ./bin/emerge --debug --verbose --depclean foo; echo $? myaction depclean myopts {'--debug': True, '--binpkg-respect-use': 'y', '--quiet-build': 'y', '--regex-search-auto': 'y', '--verbose': True} [DEBUG] Using selector: EpollSelector Signed-off-by: John Helmert III <ajak@gentoo.org>
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a1f19cdd7a598070b7eb08b3954e677aa4868ad commit 0a1f19cdd7a598070b7eb08b3954e677aa4868ad Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:27:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:28:01 +0000 sys-apps/portage: add 3.0.59 Closes: https://bugs.gentoo.org/587088 Closes: https://bugs.gentoo.org/822033 Closes: https://bugs.gentoo.org/915494 Closes: https://bugs.gentoo.org/916135 Closes: https://bugs.gentoo.org/917120 Closes: https://bugs.gentoo.org/919862 Closes: https://bugs.gentoo.org/920095 Closes: https://bugs.gentoo.org/920258 Closes: https://bugs.gentoo.org/920537 Closes: https://bugs.gentoo.org/920654 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.59.ebuild | 246 +++++++++++++++++++++++++++++++++ 2 files changed, 247 insertions(+)
