Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011: > Michal Suchanek wrote: > > > It's possible to take some random binary which is likely to be native > > (eg. /bin/sh), run ldd on it, and parse the output to determine what > > libc is actually used. > > But that's the point. Which libc is used depends on the binary. > /bin/sh might be an i386 binary and /bin/ls be amd64. How does > update-initramfs cope with that?
Currently all libraries are installed in /lib in initramfs so there should be only one flavour of binaries (i386 or amd64). On current system there is some main subarch and perhaps a few binaries of another subarch which are second grade citizens at best with very few libraries to support their installation. Is that going to change to the point that the essential binaries installed in initramfs are going to be a mix of architectures or is there still going to be main architecture in the future? If the latter then dpkg can show what the main architecture is and only binaries from packages of that architecture should be allowed in initramfs. If the former then initramfs-tools need multiarch support. I don't see any use case for multiarch in initramfs but people with blob drivers might have different opinion. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
