On 10/1/18 11:36 AM, Jacek Konieczny wrote:
From my logs of (automated) building a fresh system in a chroot: build 01-Oct-2018 09:25:17 warning: LOOP: build 01-Oct-2018 09:25:17 warning: removing glibc-2.28-5.aos1.i686 "Requires(postun): /sbin/ldconfig" from tsort relations. build 01-Oct-2018 09:25:17 warning: removing ldconfig-2.28-5.aos1.i686 "Requires(auto): rtld(GNU_HASH)" from tsort relations. [...] build 01-Oct-2018 09:25:19 glibc ################################################## build 01-Oct-2018 09:25:19 /sbin/ldconfig: No such file or directory build 01-Oct-2018 09:25:19 error: %post(glibc-2.28-5.aos1.i686) scriptlet failed, exit status 127 build 01-Oct-2018 09:25:19 ldconfig ################################################## This causes whole poldek install command to fail. Such loops make chroot installs or major updates unpredictable and when glibc is installed before ldconfig, then its %post will fail. What is worse, such loops can break installation order or other packages installed in the batch. Possible solutions: – disable autogenerated dependency for ldconfig, to force installing it before glibc – include ldconfig in the main glibc package – change glibc %post so it won't fail on ldconfig error. The easiest one, will fix the glibc installation failure, but won't break the dependency loop. Any better ideas?
make ldconfig package skip rtld(GNU_HASH) dependency. by building (linking?) it it differently; or just do rpm ignore magic? also, before merging ldconfig to glibc package, please find from git history why the split was made in first place. $ rpm -q ldconfig --requires ldconfig-6:2.27-3.x32 FHS rtld(GNU_HASH) uname(release) >= 3.4.0 rpmlib(PayloadIsLzma) <= 4.4.6-1 ldconfig-6:2.28-5.x86_64 FHS rtld(GNU_HASH) uname(release) >= 3.2.0 rpmlib(PayloadIsLzma) <= 4.4.6-1 ➔ rpm -q --what-provides 'rtld(GNU_HASH)' glibc-2.28-5.x86_64 ➔ rpm -q ldconfig ldconfig-2.27-3.x32 ldconfig-2.28-5.x86_64 ➔ -- glen _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
