Hi Benjamin, well I thought about simplifying copy_libgcc too. But it already has the signature for libdir/library and I didn't wanted to remove it, and according to the SRU process I think that changing just the way it is called is less impact-full than modifying the function itself (body and signature). On top this modification would be under debian/* (debian/initramfs/hooks/multipath) rather than in the upstream code (/usr/share/initramfs-tools/hook-functions). And there are further cases under /usr/share/initramfs-tools/* where paths are constructed similarly (and I think it's not too complicated ;-) ). And since copy_libgcc is in /usr/share/initramfs-tools/hook-functions of initramfs-tools-core hence potentially widely used, I wanted to be esp. careful about any modification, since it might "somehow somewhere" be used in a way I'm not aware of and that I cannot oversee right now.
Thought about opening a Debian bug on that as well, since the situation is the same (at least in trixie and sid). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2085157 Title: mkinitramfs fails with copy_file binary '/libgcc_s.so.[1-9]' not found To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2085157/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
