Because the ELevate process uses the CRB repository during upgrades, it is not uncommon for a future dependence on CRB to be created, resulting in errors like:
Error:
Problem: package nss_db-2.34-100.el9_4.2.x86_64 from @System requires glibc(x86-64) = 2.34-100.el9_4.2, but none of the providers can be installed
cannot install both glibc-2.34-100.el9_4.2.alma.2.x86_64 from baseos and glibc-2.34-100.el9_4.2.x86_64 from @System
cannot install both glibc-2.34-100.el9_4.2.x86_64 from baseos and glibc-2.34-100.el9_4.2.alma.2.x86_64 from baseos
cannot install the best update candidate for package glibc-2.34-100.el9_4.2.x86_64
problem with installed package nss_db-2.34-100.el9_4.2.x86_64
when dnf update is run post ELevate. This is because if CRB was not enabled pre-upgrade it is not left enabled post-upgrade even if it is used during the upgrade. Further, because of how the errors are expressed during a dnf update it is not overtly clear to users that CRB is needed as most do not even know that it is used during the ELevate process.
Until such time as ELevate can be modified to handle this situation differently, additional user documentation is needed to help users be aware of the issue and how to resolve it.
Because the ELevate process uses the CRB repository during upgrades, it is not uncommon for a future dependence on CRB to be created, resulting in errors like:
when
dnf updateis run post ELevate. This is because if CRB was not enabled pre-upgrade it is not left enabled post-upgrade even if it is used during the upgrade. Further, because of how the errors are expressed during adnf updateit is not overtly clear to users that CRB is needed as most do not even know that it is used during the ELevate process.Until such time as ELevate can be modified to handle this situation differently, additional user documentation is needed to help users be aware of the issue and how to resolve it.