Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-106141

dnf-automatic cannot detect releasever_minor

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • rhel-10.1
    • rhel-10.0
    • dnf
    • dnf-4.20.0-18.el10
    • No
    • Moderate
    • ZStream
    • rhel-swm
    • 23
    • 25
    • 0
    • False
    • False
    • Hide

      None

      Show
      None
    • Yes
    • None
    • Regression Exception
    • Hide

      dnf-automatic correctly detetects releasever_minor variable and correctly substitutes it in repository URLs.

      A test is in unit test suite of dnf. Another Beaker test in /CoreOS/dnf/Regression/RHEL-106141-dnf-automatic-detects-releasever_minor.

      Show
      dnf-automatic correctly detetects releasever_minor variable and correctly substitutes it in repository URLs. A test is in unit test suite of dnf. Another Beaker test in /CoreOS/dnf/Regression/ RHEL-106141 -dnf-automatic-detects-releasever_minor.
    • Pass
    • Automated
    • Bug Fix
    • Hide
      .DNF Automatic uses the correct RHEL minor version when the EPEL repository is enabled

      Before this update, when you used the DNF Automatic tool with the Extra Packages for Enterprise Linux (EPEL) repository enabled, the tool expanded the EPEL metalink URL to a wrong address. This caused the tool to download packages for the minor version of RHEL 10 that is still in development instead of the last released minor version. With this update, updating of the `releasever_major` and `releasever_minor` variables was fixed in the `dnf.cli.cli.Cli._read_conf_file()` method. As a result, DNF Automatic correctly detects a minor release number and downloads an EPEL repository matching the RHEL major and minor release version.
      Show
      .DNF Automatic uses the correct RHEL minor version when the EPEL repository is enabled Before this update, when you used the DNF Automatic tool with the Extra Packages for Enterprise Linux (EPEL) repository enabled, the tool expanded the EPEL metalink URL to a wrong address. This caused the tool to download packages for the minor version of RHEL 10 that is still in development instead of the last released minor version. With this update, updating of the `releasever_major` and `releasever_minor` variables was fixed in the `dnf.cli.cli.Cli._read_conf_file()` method. As a result, DNF Automatic correctly detects a minor release number and downloads an EPEL repository matching the RHEL major and minor release version.
    • Done
    • Done
    • Done
    • Not Required
    • None

      dnf-automatic wrongly detetects releasever_minor as an empty string on RHEL 10.0. As a result EPEL metalink URL is wrongly expanded to an address for a latest RHEL 10. An example:

      metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch

      expands to:

      # dnf-automatic
[...]
# grep 'metalink' /var/log/dnf.librepo.log | tail -n 1
2025-07-29T09:23:51+0200 INFO Downloading: https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64

      while expected value is:

      2025-07-29T09:22:24+0200 INFO Downloading: https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64

      Affected package: python3-dnf-4.20.0-12.el10_0.noarch

      Note that dnf program does not suffer from this problem. It is specific to dnf-automatic tool.

              rhn-support-ppisar Petr Pisar
              rhn-support-ppisar Petr Pisar
              packaging-team-maint packaging-team-maint
              Eva Mrakova Eva Mrakova
              Mariya Pershina Mariya Pershina
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: