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
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)
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?
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
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.
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
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
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
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
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
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
Processing commands for cont...@bugs.debian.org:
reopen 636352
Bug #636352 {Done: Raphael Hertzog hert...@debian.org} [dpkg] dpkg: no option
to deretmine multiarch architecture
severity 636352 wishlist
Bug #636352 [dpkg] dpkg: no option to deretmine multiarch architecture
Severity set to
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
13 matches
Mail list logo