Package: dh-debputy
Followup-For: Bug #1127427
# DEBPUTY_DEBUG=1 dpkg-buildpackage reproducer
results in a more useful log.
SD stands for debian/.debputy/scratch-dir.
dpkg-shlibdeps -T/tmp/tmp3jj0zdds
-LSD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/shlibs.local
-lSD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/libfoo0_t6q1yhs7
SD/_pb-51/generated-fs-content/no-package/tmp46gnjf4n__libfoo.so.0.0.0
works fine because
SD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/libfoo0_t6q1hs7/libfoo.so.0
is a symbolic link to libfoo.so.0.0.0 and
SD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/libfoo0_t6q1hs7/libfoo.so.0.0.0
is a symbolic link to
SD/_pb-51/generated-fs-content/no-package/tmp46gnjf4n__libfoo.so.0.0.0.
mv SD/_pb-51/generated-fs-content/no-package/tmp46gnjf4n__libfoo.so.0.0.0
SD/materialization-dirs/libfoo0/deb-root/usr/lib/x86_64-linux-gnu/libfoo.so.0.0.0
removes the actual file referenced by these symbolic links.
This explains why dpkg-shlibdeps now fails with the same -l option.
dpkg-shlibdeps -T/tmp/tmpcfrk99kc
-LSD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/shlibs.local
-lSD/_pb-51/generated-fs-content/no-package/_shlibs_materialization_dir/libfoo0_t6q1yhs7
SD/_pb-51/generated-fs-content/no-package/tmpfbfidjmj__bar
dpkg-shlibdeps: error: cannot find library libfoo.so.0 needed by
SD/_pb-51/generated-fs-content/no-package/tmpfbfidjmj__bar
