Bug 1468615 - Removing packages by mask doesn't work
Removing packages by mask doesn't work
Status: POST
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-07 10:31 EDT by Artem S. Tashkinov
Modified: 2018-05-04 08:01 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-28 07:30:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Artem S. Tashkinov 2017-07-07 10:31:06 EDT
# 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.
Comment 1 Igor Gnatenko 2017-07-12 07:15:54 EDT
Please, upgrade to F26 which contains DNF 2.x and problem is fixed there.
Comment 2 Artem S. Tashkinov 2017-07-24 17:49:34 EDT
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
Comment 3 Jaroslav Mracek 2017-07-28 07:30:45 EDT
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.
Comment 4 Artem S. Tashkinov 2017-07-28 08:01:17 EDT
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.
Comment 5 Jaroslav Mracek 2017-07-28 13:31:17 EDT
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
Comment 6 Jaroslav Mracek 2017-07-28 17:50:46 EDT
I created a patch that should provide much better user experiences (https://github.com/rpm-software-management/libdnf/pull/314).
Comment 7 Artem S. Tashkinov 2017-07-28 18:02:51 EDT
(In reply to Jaroslav Mracek from comment #6)

Thank you!
Comment 8 Fedora End Of Life 2018-05-03 04:19:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.