Excerpts from Raphael Hertzog's message of Wed Aug 03 14:32:42 +0200 2011: > On Wed, 03 Aug 2011, Guillem Jover wrote: > > I understand it's annoying to not have dpkg-architecture around for > > maintainer scripts. And duplication is not really desirable, but then > > those packages do not really need any kind of table nor mapping, just the > > matching multiarch triplet, which is already known at build time. > > The point was that initramfs-tools is arch: all and thus can't embed the > multiarch triplet for the "build arch", and he was looking for a way to > know where to pick up NSS modules to integrate in the initrd (and AFAIK > those do not appear in any ldd output since they are probably dlopen'ed). > > If you require the package to embed that information, then it must be > switched to arch: any. > > > Leaving aside the implementation details (I'd rather just define a macro > > instead), this interface is not good as it only fixes the "problem" for > > packages matching the dpkg architecture, it will not work at all for > > foreign architecture packages (including the dpkg crossgrade case). > > Yes, this assumes uniformity in the architecture of dpkg and of > the various binaries that are copied into the initrd. > > In fact the initrd must embed NSS modules for all the architectures > that have at least one binary in the initrd. It should be possible to find > the NSS modules in the same directory as libc6 itself and libc6 is > obviously reported by ldd. (And ldd is in libc-bin so it's ok) > > Michal, that's good enough, no?
Yes, that should do. Still what is a reasonable way doing so? This is more an initramfs-tools issue than dpkg then. Thanks Michal -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
