Description of problem: DNF PROVIDES does not find a package while automatic suggestion works fine and installs it Version-Release number of selected component (if applicable): Fedora 22 x64 How reproducible: Easy Steps to Reproduce: # dnf provides "*/aclocal" Last metadata expiration check performed 0:05:25 ago on Fri Nov 27 11:49:10 2015. filesystem-3.2-32.fc22.x86_64 : The basic directory layout for a Linux system Repozitář : @System (which does not print the paths - who is responsible for ditching the good old yum ?) # aclocal bash: aclocal: Příkaz nenalezen.... Nainstalovat balíček „automake“, který poskytuje příkaz „aclocal“? [N/y] y (sorry, it's Czech) ... and it is installed and works fine
*** This bug has been marked as a duplicate of bug 1192811 ***
This is not a duplicate as a mentioned ticket is nothing like this one : "DNF PROVIDES does not find a package while automatic suggestion works fine and installs it" As this is not for the first time, I am sorry to feel bloodthirsty, but I have to ask again : - who is responsible for ditching the good, old and working YUM ? - what do you give to people in Brno ?
Please take into consideration that your bugzilla report was closed because of its obscure form. > DNF PROVIDES does not find a package while automatic suggestion works fine > and installs it dnf provides "*/aclocal" finds filesystem-3.2-32.fc22.x86_64 which is in contradiction with the statement above. > (which does not print the paths - Then you complained about paths that is a duplicate of #1192811. > who is responsible for ditching the good old yum ?) Bugzilla is definitely not a right place for any kind of personal attacks. Could you please confirm that your actual issue is 'dnf provides "*/aclocal"' does not match "/usr/bin/aclocal"? I kindly ask you to use expected results field in your future bugreports.
Ok, so you just ignore incorrect behaviour of dnf, and close a bug without requester's permission. Congratulation. That is exactly the kind of behaviour I expected. Nonetheless, for future reference, DNF still does not work correctly in FC22x64 : # dnf provides "*/aclocal" Last metadata expiration check performed 1:48:58 ago on Fri Feb 12 18:19:47 2016. filesystem-3.2-32.fc22.x86_64 : The basic directory layout for a Linux system Repozitář : @System # dnf --version 1.1.5 Nainstalováno: dnf-0:1.1.5-1.fc22.noarch na 2016-01-24 18:18 Sestaveno : Fedora Project na 2015-12-18 17:32 Nainstalováno: rpm-0:4.12.0.1-14.fc22.x86_64 na 2015-12-04 15:35 Sestaveno : Fedora Project na 2015-11-20 13:22 EXPECTED RESULT : It is supposed to find automake. # rpm -ql automake | grep /aclocal$ /usr/bin/aclocal Nobody is interested in filesystem's /usr/share/aclocal This is not the only problem, so the description was written in general form. About the paths not printed - the line is enclosed in parenthesis, so consider it BTW, and I know there is another ticket about that "feature" - so your decision was to take this one line, and call this bug about a different issue a duplicate ? Really ? So the question remains unanswered - anybody responsible for QA process in RedHat Brno ?
It should list all provides/files. In the meantime use more versatile command. Please use: `dnf repoquery "*/aclocal"`. You can test all PRs in the upstream [1] if you want to join QA process ;) [1] https://github.com/rpm-software-management/dnf
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.