Colin J Thomson wrote:
> FYI, I find "dnf whatprovides" most useful,
Yeah, I use that and dnf repoquery a lot. Strictly
speaking, 'dnf provides' is the documented command, with
whatprovides kept as an undocumented alias.
> Or add a wildcard
>
> [xxx@xxx ~]$ dnf whatprovides python*-keyring
Indeed. And that works with list, info, etc. as well.
For good measure, it's good to be in the habit of quoting or
escaping the star to avoid matching a local file. :)
I happened to look through the dnf manpage and git history
and saw that 'dnf list' is documented to not match provides
(though not directly, so those of us who only skim the man
page these days might easily miss it).
The list command synopsis says:
dnf [options] list [--all] [<package-name-specs>...]
And then later in the 'SPECIFYING PACKAGES' section it says:
<package-name-spec> is similar to <package-spec> except
the provides matching is never attempted there.
The 'dnf info' command uses '<package-spec>', where
'<package-spec>' is documented to match provides. Based on
a light skimming of the dnf code, I am nearly certain this
is a documentation bug and the info command is not intended
to match provides (for better or worse).
While I was looking at it, I submitted a trivial patch to
update the 'dnf info' synopsis clarifying this:
https://github.com/rpm-software-management/dnf/pull/1004
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How much does it cost to entice a dope-smoking UNIX system guru to
Dayton?
-- Brian Boyle, UNIX/WORLD's First Annual Salary Survey
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
