Hide Forgot
Description of problem: 'man dnf' says about package specification: "... globbing characters "?, * and [ are allowed and trigger shell-like glob matching". That does not look like the case. For example: dnf list 'kernel*' works and does list various installed and available packages. But commands like dnf list 'k*3.14.0-0.rc8.git0.1.fc21' dnf list 'k*3.14.0-0.rc8.git0.1.fc21.x86_64' dnf erase 'k*3.14.0-0.rc8.git0.1.fc21.x86_64' are replying with "Error: No matching Packages to list". Replacing above "dnf" with "yum" makes all of these to work immediately. Version-Release number of selected component (if applicable): dnf-0.4.19-1.fc21.noarch How reproducible: always
'dnf list k*-3.14.0-0.rc8.git0.1.fc21.x86_64' should do the trick (the difference is in the comma after the globbing star). DNF looks at the user's input more syntactically and basically assumes that everything until the first comma is a name. Jan, it is a fact that Yum handles this. It does so by compiling list of all the NEVRAS and then reducing that to glob matches against the input. We explicitly didn't want to do that. Please analyze if we can achieve similar behavior with our current approach relatively cheaply. If yes then go for the fix please, if not we can still get away with closing this with documentation in cli_vs_yum and a proper note in command_ref at the "Specifying Packages" section, considering the reporter seems to be the only user who misses the old behavior so far. Thank you.
(In reply to Ales Kozumplik from comment #1) > 'dnf list k*-3.14.0-0.rc8.git0.1.fc21.x86_64' should do the trick While dnf list 'k*-3.14.0-0.rc8.git1.1.fc21' dnf list 'k*-3.14.0-0.rc8.git1.1.fc21.x86_64' indeed work as expected attempts like dnf list 'k*-3.14.0-*' dnf list 'k*-3.14.0-0*' result in "Error: No matching Packages to list". The funniest of all there results would likely be an output of dnf list 'kernel-*-*' I would not be able to predict a result without trying. At least something matched. In all these cases yum globbing works as documented and expected. Maybe you will be able to "document out" your way out of this mess but I would be greatly surprised.
Fixed in the upstream. Now list command also matches with nevra glob pattern not separated by nevra delimiters.
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.0.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20 then log in and leave karma (feedback).
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Due to inconsistency of the list command parameter and the rest of the commands, the patch was reverted in the upstream. The different semantic across DNF commands could be for users confusing. The use case reported here could be still achieved with the little help of the user (by providing separators) from comment 1. The <package-name-spec> parameter is documented [1]. [1] http://dnf.readthedocs.org/en/latest/command_ref.html#specifying-packages-label
(In reply to Jan Silhan from comment #7) > The different semantic > across DNF commands could be for users confusing. The use case reported here > could be still achieved with the little help of the user (by providing > separators) from comment 1. The <package-name-spec> parameter is documented > [1]. > > [1] > http://dnf.readthedocs.org/en/latest/command_ref.html#specifying-packages-label This quoted reference claims "The name specification is case-sensitive, globbing characters “?, * and [ are allowed and trigger shell-like glob matching". With a behaviour reverted to the original this is patently false. Unless a documentation will be changed to reflect the reality, if that is at all possible, this is not "could be" but it IS extremely user confusing.
I find wildcards to be far more useful when trying to compile software, and an error like "packagekit-glib not found" and there is no package called packagekit-glib not found. In the past I would have done "yum list available *glib*" and read the list, and if that didn't work "yum list available *packagekit*". What equivalent is there to this in DNF? How do I reproduce this functionality? Without this feature, troubleshooting what packages are needed is incredibly frustrating and difficult. I'm all for the cleaner codebase, and faster package-manager/parallelization/whatever but I think DNF is too young and feature-incomplete to be shipping in F22.
*** Bug 1218255 has been marked as a duplicate of this bug. ***