Dongsu Park 1b1a15e76f sys-apps/systemd: depend on lz4 >= 1.9.3-r1 ... Now that lz4 was updated to 1.9.3-r1, systemd has to depend on lz4 >= 1.9.3-r1, so that its dependency graph during the SDK stage3 could be generated correctly. Without that change, the preclean of SDK stage3 could fail because of an inverted dependency order between systemd and lz4, like following: ``` emerge --depclean --with-bdeps=y ... * Dependencies could not be completely resolved due to * the following required packages not being installed: * * >=app-arch/lz4-0_p131:0/r131=[abi_x86_64(-)] pulled in by: * sys-apps/systemd-247.6 ``` Stage3 first runs `emerge --quiet --usepkg --buildpkg --binpkg-respect-use=y --newuse -e --update --deep --with-bdeps=y @system`, which works well. After that, only the stage3 (no other stages) runs preclean, which in fact runs `emerge --depclean --with-bdeps=y` to clean up unnecessary ebuilds. That's where it fails. That happens because systemd still depends on lz4 0_p131. As a result, the main installation step of stage3 seems to first install systemd 247, and after that it updates lz4 to 1.9.3-r1. Then systemd thinks it still depends on 0_p131. When doing it the other way around, the dependency graph is correctly generated, first lz4 1.9.3-r1, then systemd 247.		2021-06-28 16:52:45 +02:00
..
src/third_party/coreos-overlay	sys-apps/systemd: depend on lz4 >= 1.9.3-r1	2021-06-28 16:52:45 +02:00