OL8: Dependency conflicts after renaming package libcgroup to libcgroup-original

[rp-ocp]

Hi, we are experiencing dependency conflicts on OL8 due to the recent rename of libcgroup to libcgroup-original. This rename appears to be an Oracle Linux specific thing not coming upstream from RHEL, hence reporting the problem here.

As the renamed package does not provide the general libcgroup but only libcgroup-original, it is no longer possible to update/install for example docker-ce packages:

$ sudo dnf update
This system is receiving updates from Unbreakable Linux Network or Spacewalk.
Last metadata expiration check: 3:19:20 ago on 2025-04-26T13:11:57 CEST.
Error:
 Problem: package docker-ce-3:26.1.3-1.el8.x86_64 from @System requires libcgroup, but none of the providers can be installed
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from @System
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from ol8_baseos
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.i686 from ol8_baseos
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.i686 from ol8_baseos_latest
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from ol8_baseos_latest
  - cannot install the best update candidate for package libcgroup-0.41-19.el8.x86_64
  - cannot install the best update candidate for package docker-ce-3:26.1.3-1.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

We have a workaround for the specific docker-ce issue, making and installing a compatibility package that requires libcgroup-original and provides libcgroup has solved it for now.

However we hope for a more clean solution where libcgroup-original also provides libcgroup. (This approach is also recommended by Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages )

It might be worth noting that other packages purely within OL8 is also affected by this and will currently lead to dependency issues:

$ sudo yum install -y libcgroup-pam libcgroup-tools
[...]
$ sudo yum update
This system is receiving updates from Spacewalk server.
Last metadata expiration check: 10:33:34 ago on 2025-04-26T06:16:52 CEST.
Error:
 Problem 1: package libcgroup-pam-0.41-19.el8.x86_64 from @System requires libcgroup.so.1()(64bit), but none of the providers can be installed
  - package libcgroup-pam-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.32)(64bit), but none of the providers can be installed
  - package libcgroup-pam-0.41-19.el8.x86_64 from @System requires libcgroup(x86-64) = 0.41-19.el8, but none of the providers can be installed
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from @System
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from ol8_baseos
  - cannot install the best update candidate for package libcgroup-pam-0.41-19.el8.x86_64
  - cannot install the best update candidate for package libcgroup-0.41-19.el8.x86_64
 Problem 2: package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1()(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.32)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.32.1)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.33)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.34)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.35)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.37)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.38)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup.so.1(CGROUP_0.39)(64bit), but none of the providers can be installed
  - package libcgroup-tools-0.41-19.el8.x86_64 from @System requires libcgroup(x86-64) = 0.41-19.el8, but none of the providers can be installed
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from @System
  - package libcgroup-original-3.2.0-1.0.1.el8.x86_64 from ol8_baseos obsoletes libcgroup <= 3.1.0 provided by libcgroup-0.41-19.el8.x86_64 from ol8_baseos
  - cannot install the best update candidate for package libcgroup-tools-0.41-19.el8.x86_64
  - cannot install the best update candidate for package libcgroup-original-3.1.0-1.0.3.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

[aburmash]

Thanks for your report.
Update, resolving this issue should be live imminently.

[yuravk]

Faced with the same issue. It breaks ELevation (upgrade) from CentOS 7 to Oracle Linux 8, like here at the workflow https://github.com/yuravk/leapp-data/actions/runs/14662285155/job/41149223280

[aburmash]

Being resolved now, repo mirroring should happen shortly, and offending packages will not be present.
Thanks for you report.

[rp-ocp]

Thank you for responding quickly to this. Will be sure to test and report back when possible

[yuravk]

@aburmash, I can confirm it is solved for me now.

Thanks.