dnf history list and dnf history info do not return non-zero exit status when transactions not found for package failure occurs

[danehlim]

Summary

dnf history subcommands list and info do not return non-zero exit status when they fail to find transactions for a specified package/<package-name-spec>. This is a bug or undocumented behavior change relative to the corresponding yum history package-list and yum history list (based on this available documentation).

Use Case

Customers may run the aforementioned history commands in their workflows and take specific actions based on if a non-zero exit status is returned or not. If they migrate to start using dnf instead of yum, these workflows may unexpectedly begin taking undesired actions.

For example, a customer may have a workflow that:

• runs yum history package-list docker (if yum is being used) or dnf history list docker (if dnf is being used)
  • if a non-zero exit status is returned, install docker package
  • otherwise, proceed with an action that makes use of docker package

In the case where dnf is being used, the customer's workflow will proceed to perform an action that makes use of docker package even in the event that no transactions (including install) exist for the docker package. Such action is undesirable for the customer.

Ideally, dnf should match the yum behavior in this case so that customers can reliably detect errors in finding transactions for a given package when running these commands and act accordingly.

Current yum Behavior

Running yum history package-list docker and yum history list docker on an instance with docker not installed returns a non-zero exit status and an error message is written to stderr.

Click here to expand for full output of commands

$ sudo yum history package-list docker 2>&1 1>/dev/null ; echo $?
Bad transaction IDs, or package(s), given
Error: Failed history packages-list
1

$ sudo yum history package-list docker ; echo $?
Loaded plugins: priorities, update-motd
Bad transaction IDs, or package(s), given
Error: Failed history packages-list
1

$ sudo yum history list docker 2>&1 1>/dev/null ; echo $?
No transactions
Error: Failed history list
1

$ sudo yum history list docker ; echo $?
Loaded plugins: priorities, update-motd
No transactions
Error: Failed history list
1

Expected dnf Behavior

Running dnf history list docker and dnf history info docker on an instance with docker not installed returns a non-zero exit status and an error message is written to stderr. This aligns with the current yum behavior.

Observed dnf Behavior

Running dnf history list docker and dnf history info docker on an instance with docker not installed returns an exit status of 0 and no error message is written to stderr.

Click here to expand for full output of commands

$ sudo dnf history list docker 2>&1 1>/dev/null ; echo $?
0

$ sudo dnf history list  docker ; echo $?
No transaction which manipulates package 'docker' was found.
0

$ sudo dnf history info docker 2>&1 1>/dev/null ; echo $?
0

$ sudo dnf history info  docker ; echo $?
No transaction which manipulates package 'docker' was found.
0

Environment Details

Instance used to run yum commands is an Amazon Linux 2 x86_64 architecture instance with the below version of yum installed:

$ yum --version
3.4.3
  Installed: rpm-4.11.3-48.amzn2.0.4.x86_64 at 2025-02-01 06:59
  Built    : Amazon Linux at 2024-04-17 06:18
  Committed: Benjamin Herrenschmidt <[email protected]> at 2024-04-10

  Installed: yum-3.4.3-158.amzn2.0.7.noarch at 2025-02-01 06:59
  Built    : Amazon Linux at 2023-10-18 18:41
  Committed: Nic Anderson <[email protected]> at 2023-10-18

Instance used to run dnf commands is an Amazon Linux 2023 x86_64 architecture instance with the below version of dnf installed:

$ dnf --version
4.14.0
  Installed: dnf-0:4.14.0-1.amzn2023.0.5.noarch at Mon Feb  3 23:39:06 2025
  Built    : Amazon Linux at Thu Jun 20 16:37:29 2024
 
  Installed: rpm-0:4.16.1.3-29.amzn2023.0.6.x86_64 at Mon Feb  3 23:38:54 2025
  Built    : Amazon Linux at Mon Feb 26 20:41:20 2024

[danehlim]

Hello there, just checking in to see if this issue has been triaged as it has been 1 month since it was opened. Are there any updates for this issue? I also have an open pull request as a proposed fix to this issue: #2214

cc: @m-blaha @ppisar @kontura

[kontura]

Hello, personally I worry that such a change now could break more users than it would help.
I would prefer just documenting the difference.

In addition dnf query commands in general behave like this:

[root@edaff9336942 /]# dnf4 repoquery non-existent; echo $?
Last metadata expiration check: 0:04:05 ago on Tue Mar 11 05:40:30 2025.
0
[root@edaff9336942 /]# dnf4 search non-existent; echo $?
Last metadata expiration check: 0:04:11 ago on Tue Mar 11 05:40:30 2025.
No matches found.
0
[root@edaff9336942 /]# dnf4 updateinfo non-existent; echo $?
Last metadata expiration check: 0:04:16 ago on Tue Mar 11 05:40:30 2025.
0
[root@edaff9336942 /]# dnf4 group list non-existent; echo $?
Last metadata expiration check: 0:04:43 ago on Tue Mar 11 05:40:30 2025.
Warning: No groups match:
   non-existent
0
[root@edaff9336942 /]# dnf4 group info non-existent; echo $?
Last metadata expiration check: 0:04:49 ago on Tue Mar 11 05:40:30 2025.
Warning: Group non-existent does not exist.
0
[root@edaff9336942 /]# dnf4 repolist non-existent; echo $?
0
[root@edaff9336942 /]# dnf4 repoinfo non-existent; echo $?
Last metadata expiration check: 0:05:58 ago on Tue Mar 11 05:40:30 2025.
Total packages: 0
0

On the other hand the list and info commands do return 1:

[root@edaff9336942 /]# dnf4 list non-existent; echo $?
Last metadata expiration check: 0:05:33 ago on Tue Mar 11 05:40:30 2025.
Error: No matching Packages to list
1
[root@edaff9336942 /]# dnf4 info non-existent; echo $?
Last metadata expiration check: 0:05:37 ago on Tue Mar 11 05:40:30 2025.
Error: No matching Packages to list
1

[danehlim]

Hello @kontura, thank you for sharing that as a mitigation dnf list and dnf info can be used in favor of dnf history list and dnf history info. I believe this mitigation should be enough for users who may fall under the use case described in this issue.

I would prefer just documenting the difference.

I agree - I would highly suggest that this difference be added to the existing "Changes in DNF CLI compared to YUM" section to fill in the documentation gap. This way, affected users also have an easily accessible point of reference for this issue.

To clarify, is the page source for the documentation also maintained in Github? If so, please feel free to direct me to the appropriate repository and I would be happy to contribute a documentation update to address this issue. Otherwise, please assist with engaging the responsible maintainers of the documentation to fill in the documentation gap.

[kontura]

Great, I think it should be in this very same repo: https://github.com/rpm-software-management/dnf/blob/master/doc/cli_vs_yum.rst

[danehlim]

Great, I think it should be in this very same repo: https://github.com/rpm-software-management/dnf/blob/master/doc/cli_vs_yum.rst

Thank you for clarifying @kontura! I have raised a pull request accordingly here: #2220.