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? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
