Describe the bug
On a system with libc 0.6.6-30, running yum update libc results in klusrmgr getting pulled in as a dependency. It seems that klusrmgr in turn triggers an update of rpm-libs.
While this operation succeeds, all subsequent yum operations prior to rebooting fail and a POPUPLOG.OS2 entry is generated:
Presumably this is a result of rpm-libs requiring a newer version of libcx, which seems like a circular problem because updating libc and libcx is dependent on the updated rpm-libs.
While a reboot restores functionality, this may present a problem for scripted install procedures when multiple yum operations are executed. Yum does not prompt for an immediate reboot after the operation, so users may not be aware that one is necessary.
Moreover, it seems risky to have klusrmgr as a dependency on libc (and thus on libcx), due to the sheer number of dependencies it triggers in turn.
To Reproduce
Steps to reproduce the behavior:
Run 'yum update libcx' (or libc, or libgcc) on a system with libc-0.6.6 (e.g. ArcaOS 5.0.0).
Describe the bug On a system with libc 0.6.6-30, running yum update libc results in klusrmgr getting pulled in as a dependency. It seems that klusrmgr in turn triggers an update of rpm-libs.
While this operation succeeds, all subsequent yum operations prior to rebooting fail and a POPUPLOG.OS2 entry is generated:
Presumably this is a result of rpm-libs requiring a newer version of libcx, which seems like a circular problem because updating libc and libcx is dependent on the updated rpm-libs.
While a reboot restores functionality, this may present a problem for scripted install procedures when multiple yum operations are executed. Yum does not prompt for an immediate reboot after the operation, so users may not be aware that one is necessary.
Moreover, it seems risky to have klusrmgr as a dependency on libc (and thus on libcx), due to the sheer number of dependencies it triggers in turn.
To Reproduce Steps to reproduce the behavior: