+++ This bug was initially created as a clone of Bug #2055033 +++ --- Additional comment from Pavel Raiskup on 2023-01-25 11:17:33 CET --- On F38 (Rawhide): $ /usr/bin/dnf5 --installroot /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/ --releasever 38 install rpm ... Running transaction [1/2] Verify package files 100% | 133.0 B/s | 167.0 B | 00m01s >>> Running pre-transaction scriptlet: filesystem-0:3.18-2.fc37.x86_64 >>> Stop pre-transaction scriptlet: filesystem-0:3.18-2.fc37.x86_64 [2/3] Prepare transaction 100% | 1.1 KiB/s | 167.0 B | 00m00s >>> Running pre-install scriptlet: rpm-0:4.18.0-9.fc38.x86_64 >>> Stop pre-install scriptlet: rpm-0:4.18.0-9.fc38.x86_64 >>> Error in pre-install scriptlet: rpm-0:4.18.0-9.fc38.x86_64 return code 2 ... Transaction failed: Rpm transaction failed. --- Additional comment from Pavel Raiskup on 2023-01-25 11:18:49 CET --- PR: https://src.fedoraproject.org/rpms/rpm/pull-request/34 --- Additional comment from Panu Matilainen on 2023-01-25 12:06:24 CET --- Ehm, this is an old bug long since fixed. Please open a new bug because it's not the same at all now. Note that adding a bash dependency to a regular scriptlet will achieve precisely nothing because /bin/sh is already an interpreter-dependency on it. (but then, I see no indication that missing bash is the cause in the latest message either) --- Additional comment from Pavel Raiskup on 2023-01-25 12:46:39 CET --- As shown, filesystem.rpm'đ %pretrans is executed first, and right after that then rpm.rpm's %pre. This is a fresh --installroot transaction, therefore I'm curious how do you guarantee that bash is installed first in the transaction. --- Additional comment from Panu Matilainen on 2023-01-25 12:56:00 CET --- It wasn't entirely clear from that snippet, but yeah I can reproduce. That's not going to be fixed by adding dependencies to rpm because it already has everything it needs. Rpm getting installed first in this scenario is entirely backwards, it's supposed to be installed *last* or almost so based on dependencies. If you compare the behavior with older dnf, that's exactly what happens. What you're seeing smells like a dnf5 bug. Please open a new bug on this and cc me on it. --- Additional comment from Panu Matilainen on 2023-01-25 12:57:47 CET --- In the meanwhile, the original issue has been fixed long since but the bug never got closed. --- Additional comment from Panu Matilainen on 2023-01-25 12:59:01 CET --- Oh and no, it does not need converting to Lua. Rpm has no %pretrans script (which is the thing *requiring* Lua) and is not a part of the early "bootstrap" set of packages (glibc,setup,filesystem etc) so there's nothing to gain from converting the script.
Panu is right, that DNF4 behaves correctly in this case, and that /bin/sh is an implicit Requires(pre) thing if %pre is used. This blocks the Mock+DNF5 experiments: https://github.com/rpm-software-management/mock/pull/1027
[pmatilai🎩︎localhost dnf5]$ find -name "*.cpp"|xargs grep rpmtsOrder [pmatilai🎩︎localhost dnf5]$ It seems to me dnf5 is not calling rpmtsOrder() at all. Which means the packages get installed rougly in the order they got added to the transaction, which is very nearly guaranteed to be totally wrong. Rpm API is stupid here, it should automatically do this stuff but doesn't. So, any API user needs to call rpmtsOrder() before rpmtsRun() or things will be terribly, horribly broken.
Just to test something else and to confirm: > # ./dnf5 --installroot /srv/test/ --releasever 38 install python3 > [...] > Running transaction > [1/2] Verify package files 100% | 216.0 B/s | 63.0 B | 00m00s > >>> Running pre-transaction scriptlet: filesystem-0:3.18-2.fc37.x86_64 > >>> Stop pre-transaction scriptlet: filesystem-0:3.18-2.fc37.x86_64 > [2/3] Prepare transaction 100% | 1.0 KiB/s | 63.0 B | 00m00s > [3/4] Installing python3-0:3.11.1-3.fc3 100% | 460.9 KiB/s | 34.6 KiB | 0 [...] > [65/65] Installing fedora-repos-rawhide 100% | 1.4 KiB/s | 2.4 KiB | 00m02s So whenver there are dependencies, the explicitly requested thing should be the last item to be installed, or nearly so.
Thanks Panu for investigation! You are completely right. I've created this PR that should fix the issue: https://github.com/rpm-software-management/dnf5/pull/250
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.