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 --all to find the advisory ID for their versiondnf updateinfo <advisory-id> info to 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.
Problem
The
dnf updateinfocommand 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 comparesapackage.nameagainst 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 detailsExpected behavior
dnf updateinfo <name-version-release.arch> --info --allshould 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
openssladvisories -- correctly filters to exact build.