Description of problem: For a Fedora 37 container, attempting to install the systemd-udev package causes the systemd-udev package to not be installed, and the "udevadm" command is not available." Version-Release number of selected component (if applicable): systemd-251.13-4.fc37 How reproducible: 100% Steps to Reproduce: 1. $ podman run -it fedora:37 2. # dnf install systemd-udev 3. Actual results: # udevadm -V bash: udevadm: command not found Expected results: # udevadm -V 251 Additional info: The package change "Split out systemd-boot-unsigned" might have had an issue that caused this for F37. This is causing an upstream stratisd test to fail: the "make clevis-test-loop" tests with tang, which use a Fedora 37 container, and install the following packages as part of the CI command: run: > dnf install -y clang cryptsetup-devel clevis clevis-luks cracklib-dicts curl device-mapper-persistent-data dbus-devel libblkid-devel make ncurses sudo systemd-devel systemd-udev xfsprogs
As another reference point, here's the same steps being executed on a Rawhide container # dnf install systemd-udev Installing: systemd-udev x86_64 253.1-4.fc39 rawhide 2.0 M Installing dependencies: cryptsetup-libs x86_64 2.6.1-1.fc39 rawhide 492 k dbus x86_64 1:1.14.6-1.fc38 rawhide 7.9 k dbus-broker x86_64 33-1.fc38 rawhide 173 k dbus-common noarch 1:1.14.6-1.fc38 rawhide 15 k device-mapper x86_64 1.02.191-1.fc39 rawhide 139 k device-mapper-libs x86_64 1.02.191-1.fc39 rawhide 177 k kbd x86_64 2.5.1-5.fc39 rawhide 429 k kbd-legacy noarch 2.5.1-5.fc39 rawhide 550 k kbd-misc noarch 2.5.1-5.fc39 rawhide 1.6 M kmod x86_64 30-4.fc38 rawhide 120 k kmod-libs x86_64 30-4.fc38 rawhide 68 k libargon2 x86_64 20190702-2.fc38 rawhide 28 k libcbor x86_64 0.7.0-9.fc38 rawhide 56 k libfdisk x86_64 2.38.1-4.fc38 rawhide 161 k libseccomp x86_64 2.5.3-4.fc38 rawhide 71 k systemd x86_64 253.1-4.fc39 rawhide 4.4 M systemd-pam x86_64 253.1-4.fc39 rawhide 344 k xkeyboard-config noarch 2.38-1.fc38 rawhide 963 k Installing weak dependencies: diffutils x86_64 3.9-3.fc39 rawhide 397 k libfido2 x86_64 1.13.0-1.fc39 rawhide 98 k libxkbcommon x86_64 1.5.0-2.fc38 rawhide 140 k qrencode-libs x86_64 4.1.1-4.fc38 rawhide 61 k systemd-networkd x86_64 253.1-4.fc39 rawhide 637 k systemd-resolved x86_64 253.1-4.fc39 rawhide 292 k Transaction Summary ======================================================================================== Install 25 Packages ... (After installation) # udevadm -V 253
Yep, I see this here too. 'dnf install systemd-udev-251.13-4.fc37' installs systemd-udev, but 'dnf install systemd-udev' does not.
FEDORA-2023-72bdb10e89 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-72bdb10e89
FEDORA-2023-72bdb10e89 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-72bdb10e89` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-72bdb10e89 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
- Make systemd-udev require systemd-boot again so that both subpackages are installed on upgrades (rhbz#2176263) so why do i need systemd-boot on machines using BIOS-boot? and why isn't bootctl and friends in "systemd-boot-unsigned" instead of "systemd-udev"? upgradeded yesterday to F37, removed "systemd-boot-unsigned" (no idea why systemd-boot as name won't be enough) on BIOS machines after it was listed by "dnf leaves" and today systemd-251.13-5.fc37.x86_64 pulled it again - that makes no sense and is what soft-dependencies are for
OK, I just tried it on a new F37 container via the update; it looks good: # dnf --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-72bdb10e89 install systemd-udev Installing: systemd-udev x86_64 251.13-5.fc37 updates-testing 1.9 M Upgrading: systemd-libs x86_64 251.13-5.fc37 updates-testing 618 k Installing dependencies: cryptsetup-libs x86_64 2.6.1-1.fc37 updates 491 k dbus x86_64 1:1.14.6-1.fc37 updates 7.7 k dbus-broker x86_64 33-1.fc37 updates 174 k dbus-common noarch 1:1.14.6-1.fc37 updates 15 k device-mapper x86_64 1.02.175-9.fc37 fedora 138 k device-mapper-libs x86_64 1.02.175-9.fc37 fedora 177 k kbd x86_64 2.5.1-3.fc37 fedora 429 k kbd-legacy noarch 2.5.1-3.fc37 fedora 551 k kbd-misc noarch 2.5.1-3.fc37 fedora 1.6 M kmod x86_64 30-2.fc37 fedora 120 k kmod-libs x86_64 30-2.fc37 fedora 68 k libargon2 x86_64 20190702-1.fc37 fedora 28 k libcbor x86_64 0.7.0-7.fc37 fedora 56 k libfdisk x86_64 2.38.1-1.fc37 fedora 160 k libseccomp x86_64 2.5.3-3.fc37 fedora 70 k systemd x86_64 251.13-5.fc37 updates-testing 4.2 M systemd-boot-unsigned x86_64 251.13-5.fc37 updates-testing 103 k systemd-pam x86_64 251.13-5.fc37 updates-testing 333 k xkeyboard-config noarch 2.36-3.fc37 updates 957 k Installing weak dependencies: diffutils x86_64 3.8-3.fc37 fedora 378 k libbpf x86_64 2:0.8.0-2.fc37 fedora 172 k libfido2 x86_64 1.11.0-3.fc37 fedora 97 k libxkbcommon x86_64 1.4.1-2.fc37 fedora 140 k qrencode-libs x86_64 4.1.1-3.fc37 fedora 61 k systemd-networkd x86_64 251.13-5.fc37 updates-testing 616 k systemd-resolved x86_64 251.13-5.fc37 updates-testing 281 k ... # udevadm -V 251
Let me clarify why I think this is a bug in dnf: We have special support for splitting packages. Both packages after the split must have Obsoletes:original-package-name < version-of-split. This has been supported for a long time, and works great also with dnf5. But if that means that dnf will refuse to install one of the packages after the split, the feature becomes unusable.
why do you need "Obsoletes:original-package-name < version-of-split" at all? make the optional subpackage a SOFT dependency of the original package and it will be pull in default setups and on machines with "install_weak_deps=0" which is not default you can remove optional sub-packages and they will not pulled again at the next update
FEDORA-2023-72bdb10e89 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
@zbyszek I think the splitting packages use-case is meant for upgrades. And it works correctly there: # dnf install systemd-udev-251.7 # dnf upgrade Upgrading: systemd-udev noarch 251-13 Installing dependencies: systemd-boot-unsigned noarch 251-13 But I do not think that's the case with `dnf install systemd-udev'. But to be honest, I would expect installation of systemd-udev, not systemd-boot-unsigned. It looks like libsolv considers both options possible. I'll prepare minimal libsolv testcase.
OK, it really looks like dnf bug. This is what debugsolver data contain: job install oneof systemd-boot-unsigned-2.0-1.fc29.noarch@split-package systemd-udev-1.0-1.fc29.noarch@split-package systemd-udev-2.0-1.fc29.noarch@split-package [forcebest,setevr,setarch] (I used versions 1.0 and 2.0 instead of 251-13)
For dnf5 it's been fixed by PR https://github.com/rpm-software-management/dnf5/pull/354
FEDORA-2023-72bdb10e89 went stable two months ago, so dnf was fixed. For later releases, https://github.com/rpm-software-management/dnf5/commit/fef4d286ba95008fcdc0944cd236410f0155e4f3 went into 5.0.8, so it's in stable too. Let's close this.