Repository navigation
updateinfo: match packages by NEVRA, not just name #2303
Description
Problem
The dnf updateinfo command only matches advisory packages by name. When a user specifies a package with version information (e.g. dnf updateinfo openssl-1:3.5.1-7.el10_1.x86_64 --info --all), no results are returned because the matching logic only compares apackage.name against the spec.
This forces users to run two commands to get advisory details for a specific package build:
dnf updateinfo <name> --list --allto find the advisory ID for their versiondnf updateinfo <advisory-id> infoto get the details
Expected behavior
dnf updateinfo <name-version-release.arch> --info --all should return only the advisories that apply to that specific package build.
Proposed fix
Extend the package matching in _apackage_advisory_installed() to also try matching the spec against the full NEVRA (name-epoch:version-release.arch), NVR, and epoch-stripped variants. This handles the common case where users omit the epoch.
Tested on RHEL 10 with openssl advisories -- correctly filters to exact build.
Activity
Allow updateinfo to match packages by NEVRA, not just name
ppisar commentedon Mar 9, 2026
I'm not an expert in updateinfo subcommand, but I think you are overloading what
dnf updateinfo openssl-1:3.5.1-7.el10_1.x86_64 --allshould do.The
--alloption means get all (i.e. pertaining older, current, and newer package version versions) advisories about a package name which is specified and installed. So the quoted command should check whether openssl-1:3.5.1-7.el10_1.x86_64 is installed, and if it is, then print all advisories about openssl package. Not an advisory about exact openssl-1:3.5.1-7.el10_1.x86_64.If you want to search for an advisory which contains openssl-1:3.5.1-7.el10_1.x86_64 (regardless the package is installed) there should be a new option. E.g. DNF5 has --contains-pkgs option (though it still insists on the package to be installed and it only matches on package names).
Also ignoring the epoch is wrong. Omitted epoch means "0" epoch. Not any epoch. This is how epoch is handled in RPM and in DNF and should be handled like that in the name of consistency.
pranlawate commentedon Mar 9, 2026
Thank you for the detailed review.
The real-world use case driving this: a support engineer (or user) needs to find when a specific package build's errata was released. Today that requires two commands:
dnf updateinfo list openssl --all# find the advisory IDdnf updateinfo info <advisory-id> --all# find the release dateOr a one-liner workaround that's unnecessarily complicated:
Update_Id=$(dnf updateinfo openssl --list --all | grep 1.1.1k-14.el8_6.x86_64 | awk '{print ($1 == "i" ? $2 : $1)}'); dnf updateinfo $Update_Id --info | grep UpdatedThis is manageable for one package. It becomes impractical when a user has a list of packages and needs errata dates for each.
My initial approach was to extend to accept NEVRA because updateinfo already has a large number of options and sub-options -- adding another one increases the interface surface users need to learn. Extending felt like the more natural path since users already pass package identifiers there.
That said, I'm open to implementing this as a new option (e.g. --contains-pkgs to align with DNF5) if that's the preferred interface. I'd also fix the epoch handling to treat omitted epoch as 0.
Could you confirm that direction?
ppisar commentedon Mar 9, 2026
I understand that the command interface is already complicated. That's why we need to be careful when adding new features.
Now I cannot confirm any direction. I need to hear opinion of other maintainers. I will try go it on Thursday.
pranlawate commentedon Mar 9, 2026
Understood.
I will await your update and other maintainers point of view.
ppisar commentedon Mar 12, 2026
The maintainer discussed this topic and their opinion is that:
"dnf updateinfo" command was designed to query an affected system, not to search for an arbitrary advisory and thus the proposed interdace does not fit well.
There should be a new option, e.g.
--contains-build(or completely new subcommand) , which would change meaning of the positional argument from a package name to NEVRA (or its shortened forms), which would search all advisories containing a package build matching the positional argument, and which would not limit to installed packages.DNF4 is being replaced with DNF5 and feature request like this should aim DNF5 first.
pranlawate commentedon Mar 16, 2026
Thanks for discussing this @ppisar .
I discussed this with @kontura about how
updateinfo listonly works on packages that have a version installed on the system to even show up for --installed or --available. I understand well that it would makes better sense to have a separate flag.Alright, I will revert the changes in updateinfo to keep matching to package name and create a new flag --contains-build that when used will take NEVRA(or any of its combination) as input and searches for it regardless of whether it's installed or not. Also do something to assume 0 epoch when it's not specified.
Will then update the docs and sqaush it all into one commit for 2304 so you can review it all together.
Add --contains-build option to updateinfo command