Bug 1083679 - dnf globbing does not really work
dnf globbing does not really work
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
:
: 1218255 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-02 13:41 EDT by Michal Jaegermann
Modified: 2016-10-11 12:57 EDT (History)
7 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.0.8-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-31 19:57:17 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 Michal Jaegermann 2014-04-02 13:41:27 EDT
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
Comment 1 Ales Kozumplik 2014-04-03 03:01:04 EDT
'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.
Comment 2 Michal Jaegermann 2014-04-03 13:45:32 EDT
(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.
Comment 3 Honza Silhan 2014-05-02 09:06:08 EDT
Fixed in the upstream. Now list command also matches with nevra glob pattern not separated by nevra delimiters.
Comment 4 Fedora Update System 2014-05-28 08:08:51 EDT
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
Comment 5 Fedora Update System 2014-05-28 19:48:44 EDT
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).
Comment 6 Fedora Update System 2014-05-31 19:57:17 EDT
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.
Comment 7 Honza Silhan 2015-03-17 09:06:26 EDT
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
Comment 8 Michal Jaegermann 2015-03-17 11:54:21 EDT
(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.
Comment 9 davidzgumberg 2015-04-06 17:42:33 EDT
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.
Comment 10 Radek Holy 2015-05-04 08:40:27 EDT
*** Bug 1218255 has been marked as a duplicate of this bug. ***
Comment 11 Richard S. Hendershot 2015-05-05 08:55:34 EDT
*** Bug 1218255 has been marked as a duplicate of this bug. ***

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