Bug#636352: dpkg: no option to deretmine multiarch architecture
Excerpts from Jonathan Nieder's message of Tue Aug 02 21:01:34 +0200 2011: Hi, Raphael Hertzog wrote: On Tue, 02 Aug 2011, Michal Suchanek wrote: Also you can have libraries for *both* subarchs and there is no way to tell on what arch you are actually running, /etc/ld.so.conf will surely include both. Sorry I have been a bit quick to close the report. But it's more a wishlist request than a real bug. I still don't understand the use case. Why does update-initramfs care what the native arch is? During a crossgrade, what is the native arch? Does some heuristic like taking NSS modules from the same directory as libc work? I have usually 2 copies of libc on a system, up to 3 can be installed. 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. Quite convoluted. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
Excerpts from Raphael Hertzog's message of Tue Aug 02 20:43:21 +0200 2011: reopen 636352 severity 636352 wishlist retitle 636352 dpkg: provide a way to query the multiarch path component without dpkg-dev thanks On Tue, 02 Aug 2011, Michal Suchanek wrote: Also you can have libraries for *both* subarchs and there is no way to tell on what arch you are actually running, /etc/ld.so.conf will surely include both. Sorry I have been a bit quick to close the report. But it's more a wishlist request than a real bug. 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? 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. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
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). Ccing Steve and Guillem to have their feedback. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
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
Bug#636352: dpkg: no option to deretmine multiarch architecture
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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
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
Bug#636352: dpkg: no option to deretmine multiarch architecture
On 2011-08-03 13:11 +0200, Michal Suchanek wrote: 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). That seems to be wrong: , | $ lsinitramfs /boot/initrd.img-$(uname -r) | grep -c $(dpkg-architecture -qDEB_HOST_MULTIARCH) | 9 ` 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? Most systems will probably not need binaries from foreign architectures, but they should already work if you can execute them at all. 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. The copy_exec function that installs a binary into the initramfs runs ldd and installs the libraries that ldd reports. Don't you think this is sufficient? Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
Hi! On Wed, 2011-08-03 at 11:25:37 +0200, Raphael Hertzog wrote: On Wed, 03 Aug 2011, Michal Suchanek wrote: 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. Jonathan already mentioned this, but I'll repeat, I don't really see the point in this, and I don't think this is the right direction to take. 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 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). 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). I think the correct solution here is substitution at build time, debhelper already supports this to inject its own snippets, it would be nice to have something like #DEBHELPER_ARCH# and #DEBHELPER_MULTIARCH# for example (or maybe even something more generic). regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
Excerpts from Sven Joachim's message of Wed Aug 03 13:58:50 +0200 2011: On 2011-08-03 13:11 +0200, Michal Suchanek wrote: 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). That seems to be wrong: , | $ lsinitramfs /boot/initrd.img-$(uname -r) | grep -c $(dpkg-architecture -qDEB_HOST_MULTIARCH) | 9 ` Yes, libraries are installed in the place where they are looked up by ldd so long as they are located automatically by ldd and not copied manually. You can find gems such as these which will break once more libraries get multiarch locations: chroot/usr/share/initramfs-tools/hooks/plymouth: copy_exec /usr/lib/pango/1.6.0/modules/pango-basic-fc.so chroot/usr/share/initramfs-tools/hooks/plymouth: copy_exec /usr/lib/libpango-1.0.so.0 As pango is used by many applications which are used as 32bit binaries it is a likely candidate. 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? Most systems will probably not need binaries from foreign architectures, but they should already work if you can execute them at all. So long as you can find them during initramfs creation and pack them into the initramfs, yes. 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. The copy_exec function that installs a binary into the initramfs runs ldd and installs the libraries that ldd reports. Don't you think this is sufficient? Not for NSS modules which are loaded dynamically by libc and not reported as dependencies by ldd. The same applies to the pango modules I would expect. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
Package: dpkg Version: 1.16.0.3 Severity: normal Since libraries are allowed to install in /lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) and it is necessary to pick libnss_dns.so.* from there to have DNS lookup working in initramfs dpkg-architecture from dpkg-dev (and hence build-essintials) is required to build a decent initramfs for netbooting. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (900, 'stable'), (500, 'testing'), (410, 'unstable'), (200, 'experimental'), (111, 'oldstable'), (107, 'natty-updates'), (107, 'natty') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 8.5-1GNU core utilities ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii xz-utils5.0.0-2 XZ-format compression utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt0.8.10.3+squeeze1 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
reopen 636352 severity 636352 wishlist retitle 636352 dpkg: provide a way to query the multiarch path component without dpkg-dev thanks On Tue, 02 Aug 2011, Michal Suchanek wrote: Also you can have libraries for *both* subarchs and there is no way to tell on what arch you are actually running, /etc/ld.so.conf will surely include both. Sorry I have been a bit quick to close the report. But it's more a wishlist request than a real bug. 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. 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) You can also find a way to embed the correct path for all architectures by generating the mapping at build time: $ dpkg-architecture -L | (while read arch; do path=$(dpkg-architecture -a$arch -qDEB_HOST_MULTIARCH 2/dev/null); echo $arch $path; done) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636352: dpkg: no option to deretmine multiarch architecture
Hi, Raphael Hertzog wrote: On Tue, 02 Aug 2011, Michal Suchanek wrote: Also you can have libraries for *both* subarchs and there is no way to tell on what arch you are actually running, /etc/ld.so.conf will surely include both. Sorry I have been a bit quick to close the report. But it's more a wishlist request than a real bug. I still don't understand the use case. Why does update-initramfs care what the native arch is? During a crossgrade, what is the native arch? Does some heuristic like taking NSS modules from the same directory as libc work? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
