This issue blocks the most of Microsoft Linux test automation run-time with RHEL 8.x. Many places use 'yum install rpm-build'

Could you please copy&paste relevant lines from /var/log/dnf.log? Also, I wonder if "8.0" is the correct release version in the path. Would you mind doing:

1) check if /etc/yum/vars/releasever exists
1.1) if so, what's inside?
1.2) else:
1.2.1) echo 8 > /etc/yum/vars/releasever
1.2.2) run "yum install..." again and see what happens.
1.2.3) restore/delete /etc/yum/vars/releasever

Please also share what's in the yum repository file that defines the CodeReady repository.

Created attachment 1650079 [details]
dnf.log

(In reply to Radek Bíba from comment #2)
> Could you please copy&paste relevant lines from /var/log/dnf.log? Also, I
> wonder if "8.0" is the correct release version in the path. Would you mind
> doing:
> 
> 1) check if /etc/yum/vars/releasever exists
> 1.1) if so, what's inside?
> 1.2) else:
> 1.2.1) echo 8 > /etc/yum/vars/releasever
> 1.2.2) run "yum install..." again and see what happens.
> 1.2.3) restore/delete /etc/yum/vars/releasever
> 
> Please also share what's in the yum repository file that defines the
> CodeReady repository.

Thanks Radek, attached dnf.log, 8 is expected, but 8.0 is not, after install rpm-build, the version changed from 8 => 8.0.
1.2) /etc/yum/vars/releasever not exists.
1.2.1) echo 8 > /etc/yum/vars/releasever is a work around.
1.2.2) yum install works
1.2.3) remove /etc/yum/vars/releasever => issue happen again, restore => issue resolved

Attached the only repo file, if the version is 8, the URL is valid.

Created attachment 1650080 [details]
dnf.log

Created attachment 1650081 [details]
repo file

Thank you. So it's a problem with the way the $releasever variable, which is used in the paths in the repo file, gets resolved. Interestingly, it really only happens after updating some package as part of the rpm-build installation.

This is what happens on a clean RHEL 8.0 system (in AWS, but I'm pretty sure Azure gives the same results):

# /usr/libexec/platform-python -c "import dnf; yb = dnf.Base(); print(yb.conf.releasever)"
8

Then:

Installing:
 rpm-build                                           x86_64                          4.14.2-25.el8                             rhui-rhel-8-appstream-rhui-rpms                          169 k
Upgrading:
 rpm-libs                                            x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                             336 k
 rpm-plugin-systemd-inhibit                          x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                              74 k
 rpm                                                 x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                             539 k
 rpm-plugin-selinux                                  x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                              73 k
 python3-rpm                                         x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                             156 k
 rpm-build-libs                                      x86_64                          4.14.2-25.el8                             rhui-rhel-8-baseos-rhui-rpms                             152 k

# /usr/libexec/platform-python -c "import dnf; yb = dnf.Base(); print(yb.conf.releasever)"
8.0

Would it be acceptable for you to update dnf and its dependencies before installing the make package? (You *should* then be getting 8 as the releasever.)

It seems you're running dnf-4.0.9 which was part of RHEL 8.0 - and that's pretty old and we have fixed many bugs since then.

Could you upgrade dnf, libdnf and rpm to be in higher or equal versions to following?
dnf-4.2.7-6.el8
libdnf-0.35.1-8.el8
rpm-4.14.2-25.el8


I think it may have something to do with following change in RPM:
* Wed Mar 06 2019 Panu Matilainen <pmatilai> - 4.14.2-10
- Return all string data as surrogate-escaped utf-8 in Python 3 (#1631292)

You either need to use both dnf and rpm in old versions or new versions.
The combination of old and new unfortunately doesn't work.

Upgrading dnf & libdnf package mitigates the issue.

/usr/libexec/platform-python -c "import dnf; yb = dnf.Base(); print(yb.conf.releasever)"
8

rpm -qa | grep dnf
dnf-4.0.9.2-5.el8.noarch
libdnf-0.22.5-5.el8_0.x86_64


yum update dnf

rpm -qa | grep dnf
libdnf-0.35.1-9.el8_1.x86_64
dnf-4.2.7-7.el8_1.noarch

/usr/libexec/platform-python -c "import dnf; yb = dnf.Base(); print(yb.conf.releasever)"
8

Verified and confirmed 'yum update dnf rpm' prior to 'yum install rpm-build' is the only workaround to sustain 'yum repolist'.

We should probably add a safeguard to force upgrading the packages together:

rpm.spec / python3-rpm :
Conflicts: python3-dnf < dnf-4.2.17-3

dnf.spec / python3-dnf :
Requires: python3-rpm >= 4.14.2-35


Acceptance Criteria: verify that if one package is upgraded, the other gets upgraded too (and vice versa)
No automated test is required.


Setting high priority because it might have impact of end users if they update packages separately.

I created a PR that increases the required version of python3-rpm for dnf: https://github.com/rpm-software-management/dnf/pull/1577

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1823