This should ease writing maintainer's scripts. See the command output: $ dnf repoquery --disablerepo=* --enablerepo hell \ --repofrompath=hell,http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/ \ --whatrequires postgresql-jdbc 2>/dev/null Added hell repo from http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/ Last metadata expiration check: 4:43:42 ago on Wed Jul 20 07:54:15 2016. libreoffice-base-1:5.2.0.1-1.fc25.x86_64 weka-0:3.6.14-1.fc25.noarch While I would expect: $ dnf repoquery --disablerepo=* --enablerepo hell \ --repofrompath=hell,http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/ \ --whatrequires postgresql-jdbc 2>/dev/null libreoffice-base-1:5.2.0.1-1.fc25.x86_64 weka-0:3.6.14-1.fc25.noarch
I would like to inform you about possibility to use -q or --quiet option. In combination with a non-interactive command it shows just the relevant content. It suppresses messages notifying about current state or actions of DNF. It should solve the problem, therefore I am closing the bug. Please if you will find any further problem, don't hesitate to report it.
I'm thinking that reporter is correct.
Fixed in PR: https://github.com/rpm-software-management/dnf/pull/673 If anything else appear in stdout, please report it again.
This seems like a terrible idea. It might just be better to have a flag for suppressing info messages as well as warnings, etc. (I thought we do with --quiet?) Warnings are for potential problems, not informational messages. The behavior done in PR 673 should be reverted.
(In reply to Neal Gompa from comment #4) > This seems like a terrible idea. It might just be better to have a flag for > suppressing info messages as well as warnings, etc. (I thought we do with > --quiet?) Well, that's different thing. The idea was about moving some writes from stdout to stderr, so stdout is (ideally) easily parseable. > Warnings are for potential problems, not informational messages. The > behavior done in PR 673 should be reverted. Thanks for the point, I tend to agree - this is not the ideal fix.
Ok, but this is not the first change of that kind. The information about Last metadate ... is now also on stderr. Also -q option behave differently. Now it suppress all (info, debud, warning, error, critical), but originally it only suppress info. From my point of view if output of repoquery is used for any script, it should use -q option, therefore any adjustments are nonsense. We can really play with it, but one user will request that and another something different.
I took this bug as an advice only. That's how things work in our GNU/Linux ecosystem (at least) .. data goes to stdout, and warnings/errors go to stderr -> which makes it trivial to parse what I ask for and to suppress warnings by '2>/dev/null' (-q is not important usually, unless you want to suppress some stdout output, too). > We can really play with it, but one user will request that and another > something different. I believe that the behavior I explained is what random hacker would expect, but that's really just a matter of quality of implementation, not a huge deal. Neither a blocker of any kind for me - with a bit of carefulness I can parse the output anyway or hack my own repoquery-like script in python as a replacement for repoquery, it is just not that convenient. So pick the resolution arbitrarily.
My 5c: The original yum-based repoquery was first and foremost designed for as a scripting tool in the traditional unix sense - zero extra output *by default*, errors to stderr and none of the interactive-text-ui-thing that yum itself is/was. Like yum, dnf provides list and search etc commands for interactive work, with progress reports and all that. So please preserve the hardcore scripting orientation in repoquery, it always was a specialized tool just for that.
Well here is the new solution: https://github.com/rpm-software-management/dnf/pull/681
Fixed in dnf-2.0.1-1 and released into rawhide