Hi Jochen, On Thu, Aug 22, 2024 at 08:51:23AM +0200, Jochen Sprickerhof wrote: > systemd 256.5-1 changed the behaviour and now creates a lib64 -> usr/lib > symlink so the workaround here no longer works. This should fix it:
Thanks for reporting. > --- a/debian/preinst > +++ b/debian/preinst > @@ -7,7 +7,7 @@ if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then > if [ -L "$DPKG_ROOT/$d" ]; then > target=$(readlink "$DPKG_ROOT/$d") > if [ "$target" != "usr/$d" ]; then > - if [ "$d" = lib64 ] && [ "$target" = "usr/lib/#DEB_HOST_MULTIARCH#" > ]; then > + if [ "$d" = lib64 ] && [ "$target" = "usr/lib/x86_64-linux-gnu" ] || > [ "$target" = "usr/lib" ]; then > # Work around https://github.com/systemd/systemd/issues/33919 > echo "Fixing bad /$d symbolic link created by systemd-nspawn." > if [ -d "$DPKG_ROOT/usr/$d" ]; then I'd appreciate if we could defer applying this fix a little, because > Do we have a related systemd bug to stop creating those links? we should fix the cause before the symptom and then also reference the systemd fix in the base-files.preinst in order to get an idea when it is applicable to remove the workaround when looking at this in five years. Did you already report this bug on the systemd side upstream or downstream? Indicating "no" allows one of us filing it while avoiding duplicates or you may do it yourself. Helmut
