dnf5
dnf5 copied to clipboard
rpm-software-management
dnf5 repoquery writes repo update output to stdout not stderr
Unlike dnf4, dnf5 repoquery outputs repo metadata update output to stdout, so it gets prepended to repoquery output, which is pretty bad.
Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=2223347
$ dnf5 -q --refresh rq rawhide xz 2>/dev/null
Fedora - Rawhide - Developmental packages for the next Fedora release 100% | 33.6 KiB/s | 40.4 KiB | 00m01s
Fedora - Rawhide - Developmental packages for the next Fedora release 100% | 247.8 KiB/s | 488.2 KiB | 00m02s
xz-1:5.4.6-3.fc41.x86_64
Note that even --quiet does not prevent the output
The broken --quiet option should be fixed by: https://github.com/rpm-software-management/dnf5/commit/328dcead80a3cb611ef551e1768f059a54ee190d now it should hide also the repo metadata update output.
Getting back to this.
As @kontura mentioned, using the -q or --quiet option now suppresses the repository metadata update messages.
Regarding sending repository metadata update messages to standard output, POSIX specifies that conventional output goes to stdout, while diagnostics go to stderr. In my opinion, keeping the user informed about the current action fits the conventional output category, so this approach seems appropriate.
For machine-parsable output, repoquery already supports this via the --queryformat option, allowing you to customize the output format, e.g., dnf5 repoquery -q --queryformat "machine_out: %{full_nevra}\n".
Therefore, I'm closing this issue and consider it resolved.
This behavior is unexpected and unpleasant to work with. "conventional output" is the result of the query. "repository metadata update messages" are diagnostics/progress.
The mere availability of machine_out queryformat does not make this not a bug.
What Miro said. This is just broken. It's certainly possible to work around the issue, but as multiple people who need to use this interface for scripting have said, the current way how the output is split is annoying and hard to use.
This behavior is unexpected and unpleasant to work with.
... snip ...
This is just broken. It's certainly possible to work around the issue, but as multiple people who need to use this interface for scripting have said, the current way how the output is split is annoying and hard to use.
Understood. We'll look into it.