# rpm -qa | grep 4.10.4 kernel-4.10.4-200.fc25.x86_64 kernel-modules-4.10.4-200.fc25.x86_64 kernel-devel-4.10.4-200.fc25.x86_64 kernel-core-4.10.4-200.fc25.x86_64 # dnf remove '*4.10.4*' No match for argument: *4.10.4* Error: No packages marked for removal. WTF? I'm running fully updated Fedora 25 x86-64. # rpm -q dnf dnf-1.1.10-6.fc25.noarch # rpm -qa | grep hawk hawkey-0.6.4-3.fc25.x86_64 python3-hawkey-0.6.4-3.fc25.x86_64 This used to work in yum.
Please, upgrade to F26 which contains DNF 2.x and problem is fixed there.
This is reproducible in Fedora 26 with all updates installed as of 2017.07.25: # dnf remove '*4.11.3*' No match for argument: *4.11.3* Error: No packages marked for removal. # rpm -qa | sort | grep '4.11.3' kernel-4.11.3-200.fc25.x86_64 kernel-core-4.11.3-200.fc25.x86_64 kernel-devel-4.11.3-200.fc25.x86_64 kernel-modules-4.11.3-200.fc25.x86_64 dnf-2.5.1-1.fc26.noarch
The problem here is, that dnf needs a separators "-" between NEVRA parts. Also name of package is required information but can ge replaced by "*". I can provide an examples: If you ou want to remove every package with version 4.11.3. The valid argument for DNF would be: "*-4.11.3" (NAME{"*"}-VERSION{"4.11.3"}) The reduction in search possibilities cannot be changed because it also reduce the possibility of incorrect interpretation especially with globs you have to careful. Hope that my answer helped you. If you think that the restriction is unacceptable, don't hesitate to reopen the bug report.
I'm going to reopen this bug report because it needs a better discussion. I really really (sic!) don't like the new behavior for several reasons: 1) Take the kernel package for instance: kernel-4.11.7-200.fc25.x86_64 kernel-core-4.11.7-200.fc25.x86_64 kernel-devel-4.11.7-200.fc25.x86_64 kernel-headers-4.11.7-200.fc25.x86_64 kernel-modules-4.11.7-200.fc25.x86_64 kernel-tools-4.11.7-200.fc25.x86_64 kernel-tools-libs-4.11.7-200.fc25.x86_64 How the user is supposed to know that "-200" is _not_ part of the package name? Doesn't make any sense to me. 2) What if the user wants to match "*fc24*"? For instance, I have these packages installed: [root@localhost ~]# rpm -qa | grep fc24 xfce-bluetooth-0-0.5.20150130git.fc24.x86_64 xorg-x11-xauth-1.0.9-5.fc24.x86_64 xfce4-clipman-plugin-1.2.6-8.fc24.x86_64 rdesktop-1.8.3-3.fc24.x86_64 wavemon-0.7.6-7.fc24.x86_64 [root@localhost ~]# dnf remove '*fc24*' No match for argument: *fc24* Error: No packages marked for removal. 3) What if I want to rid myself of i686 packages? I have over a hundred of them. dnf remove '*i686*' should work but it doesn't. In summary, IMO, the full package name (%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}) should be used as a basis of matching except for the ".rpm" part. It's been this way historically and it worked very well. > The reduction in search possibilities cannot be changed because it also reduce the possibility of incorrect interpretation especially with globs you have to careful. Let me disagree with you here. Most people never run dnf with the "-y" switch which means you always have a chance of verifying that the selection you've made matches your expectations. One last remark: '*' should ideally work as any number of letters, including none, e.g. a lot like `find . -iname '*txt*'` which will find any txt files, including "123.txt" and "txt.123". P.S. As an IT pro I can use rpm/sed/awk/sed/tr/whatever to solve this issue but my reasoning is that pattern matching should be made easy for the average user who doesn't want to dig deep into the internals of RPM.
Ok, I will try to make a patch, but it doesn't mean, that community will agree to merge it. Note: We don't match string that are provided by user to full NEVRA of package. The first we have to split it into name, version, ... and then try to look if this combination is valid. The splitting often provide several possibilities, therefore DNF has a lot to do. So far DNF supports: NEVRA NEVR NEV NA NAME Where: N - name E - epoch (optional) V - version A - arch
I created a patch that should provide much better user experiences (https://github.com/rpm-software-management/libdnf/pull/314).
(In reply to Jaroslav Mracek from comment #6) Thank you!
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.