Description of problem: When you run: # dnf foo No such command: foo. Please use /usr/bin/dnf --help User have no idea where they can get command foo (in my case 'copr'). It would be nice to give them hints to either install dnf-plugins-core or check available plugins by running dnf search dnf-plugin The same apply to running dnf foo --help on unknown command.
Hi, thanks for the report. We can blindly write message that it could be a plugin command. I don't think it's a good idea to store all commands from dnf-plugins-core in dnf.
Miroslav's idea of suggesting "dnf search dnf-plugin" wouldn't necessarily work all that well. For example, in the specific case of the copr subcommand, that's provided by dnf-plugins-core, but the metadata search results don't indicate that. An alternative might be to adopt a packaging recommendation that components providing dnf subcommands include a virtual provides for "dnf-command(command)". Then dnf could blindly suggest trying that, with it being up to the plugin package to supply them. That is, something like: $ dnf foo No such command: foo. Please use 'dnf --help' or try 'dnf install dnf-command(foo)'
I was suggesting 'dnf search dnf-plugin' only as option, so it give user hint, where the plugin can be. But yes, having virtual provides dnf-command(foo) is very nice. I like it.
(In reply to Jan Silhan from comment #1) > Hi, thanks for the report. We can blindly write message that it could be a > plugin command. I don't think it's a good idea to store all commands from > dnf-plugins-core in dnf. Yes, that's the best we can do. I would be against any random solutions like searching virtual provides etc, the use case is far too marginal to marginal to deserve extreme measures like that. git doesn't tell you the package you need to install when 'git send-email' doesn't exist either.
I actually like Nick's idea - there would be no additional garbage in dnf code. We will only extend "no-such-command" message, after that it's up to the user what he will do. Provides in dnf-plugins-core wouldn't hurt. Additionally in Description should be named plugins or/and commands as well because of "dnf search" command. It's the same approach as in debian where if bash command you type doesn't exist in /usr/bin it gives you hint that you could try "apt-get install ...".
Hint added to DNF and extended description of dnf-plugins-core which plugins it contains. Solution with provides was rejected - it's dependent on packaging format of plugins and we should treat the same rpm packed plugins, python eggs, etc.
dnf-0.6.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnf-0.6.1-1.fc21
Package dnf-0.6.1-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.6.1-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10199/dnf-0.6.1-1.fc21 then log in and leave karma (feedback).
dnf-0.6.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Hello, just in case that someone finds this report: We have cancelled the decision made in comment #4: see bug 1208773.