Description of problem: systemd 252-8 added Obseletes on itself between -boot-unsigned and -udev due to some files being split between these two subpackages. Ideally, the newer NEVR (252-14) would allow -udev to be installed, but in testing, systemd-udev still resolves to systemd-boot-unsigned even with the -14 RPMs in a repository together. Version-Release number of selected component (if applicable): 252-8, 252-14 How reproducible: Always Steps to Reproduce: 1. dnf config-manager --set-enabled crb 2. dnf install systemd-udev Actual results: systemd-udev package is installed Expected results: systemd-boot-unsigned is installed instead. Additional info: [root@255594769a63 /]# dnf -y install systemd-udev Dependencies resolved. ========================================================================================================================== Package Architecture Version Repository Size ========================================================================================================================== Installing: systemd-boot-unsigned x86_64 252-8.el9 crb 124 k Transaction Summary ========================================================================================================================== Install 1 Package [root@255594769a63 /]# ls a repodata systemd-libs-252-14.el9.x86_64.rpm systemd-udev-252-14.el9.x86_64.rpm systemd-252-14.el9.x86_64.rpm systemd-pam-252-14.el9.x86_64.rpm [root@255594769a63 /]# dnf --repofrompath=a,/a/ install systemd-udev Added a repo from /a/ Last metadata expiration check: 0:00:16 ago on Thu Mar 30 17:46:54 2023. Dependencies resolved. ========================================================================================================================== Package Architecture Version Repository Size ========================================================================================================================== Installing: systemd-boot-unsigned x86_64 252-8.el9 crb 124 k
Hey folks, any updates on this one? As it's quite unpleasant packaging bug with not straightforward workaround, that supposedly should be relatively easy to fix as it's more about metadata of packages rather then their content?
Hello, May I ask what your use case is? On a regular system, systemd-udev is always installed, and I wouldn't recommend uninstalling it. Are you using containers with systemd-udev? Thanks I'm going to investigate.
I was able to reproduce the issue using the centos/centos:stream9 container.
Hey, Yes, usecase is exactly container image. Or the ones, that are built using `dnf --installroot=/var/lib/machines/container_name install --nodocs rootfiles coreutils dnf` Then we're trying to install gluster inside the container and use `systemd-tmpfiles-setup-dev.service` that is provided by systemd-udev package, that requires a nasty workaround to get installed for couple of months now.
We encountered this in Fedora too: https://bugzilla.redhat.com/show_bug.cgi?id=2176263. It was fixed for both dnf and dnf5 via updates.
Dmitriy, You can use `dnf install systemd-udev-252-15.el9` as a workaround for now. I'm going to move this bug to dnf. Please see the comment from Zbigniew above.
Yeah, I'm aware of workaround, but as I said earlier - it's quite nasty. So eventually it hit our users on stable releases of our tooling, so we have to retroactively backport patches to fix the regression. But now we also need to keep track on versions that are provided and update systemd-udev version in the code each time new one is being released and backport that to all stable branches that have support of CentOS 9 Stream, which is quite a PITA. Or, add extra steps to check mirrors for available packages, parse them and apply versioning in place, which I'd love avoid frankly speaking. So thanks for taking time to look into that, hopefully it will be fixed soonish :)
*** Bug 2229539 has been marked as a duplicate of this bug. ***