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
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
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
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
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
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
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,
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
14 matches
Mail list logo
