Excerpts from Raphael Hertzog's message of Wed Aug 03 11:25:37 +0200 2011: > On Wed, 03 Aug 2011, Michal Suchanek wrote: > > > It's also unlikely to be quickly fixed at this point. It would basically > > > require to rewrite a large part of dpkg-architecture in C. > > > > Why the need to rewrite it? > > Because we don't want the dpkg package to depend on perl. (But for > dpkg-dev it's fine) > > > > Note that if your package is "arch: any", you can embed the multiarch > > > path in your package at build time. (This is currently not the case for > > > initramfs-tools) > > > > dpkg is arch:any so it can embed the multiarch architecture at build > > time just like any other package. > > True enough, but it would somewhat duplicate the information. But this > could be acceptable in the mean time I guess. At least better than > embedding it in multiple other packages. > > The official interface would be "dpkg --print-multiarch-path" and > it would just "cat /usr/lib/dpkg/multiarch-path" that would be created > at build time (and when we have the required code to directly parse > the various /usr/share/dpkg/*table then we can drop that file). >
It's also possible to ldd /bin/sh (or busybox or something) to determine what libc is in use and where its nss modules are to pick them for initramfs but I think it would be better to have an official interface to tell what subarch the system is running rather than multitude of shell snippets giving varying results in bordercase situations. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
