Bug#710769: dpkg-checkbuilddeps: unsatisfyable Multi-Arch: none cross build dependencies not listed as missing
Package: dpkg-dev
Version: 1.16.10
Severity: normal
User: crossbu...@debian.org
Usertags: cross
There is an inconsistency between `dpkg-checkbuilddeps -a${arch}` and
`apt-get build-dep -a${arch}` behavior. Here we test on the source
package bash which Build-Depends on autoconf which is Multi-Arch: none.
$ dpkg-checkbuilddeps -aarmel
dpkg-checkbuilddeps: Unmet build dependencies: libncurses5-dev sharutils time
$ apt-get build-dep -aarmel bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for bash cannot be satisfied because the package
autoconf cannot be found
The package autoconf is not listed as an unmet build dependency by
dpkg-checkbuilddeps. Apt-get lists it as being unsatisfiable. It is my
understanding that the apt behavior is the correct one as autoconf is
Multi-Arch: none and can therefore not be used to satisfy the cross
build dependencies of bash. Therefore, autoconf should also appear in
the list of unmet build dependencies as given by dpkg-checkbuilddeps.
Thanks, josch
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710769: dpkg-checkbuilddeps: unsatisfyable Multi-Arch: none cross build dependencies not listed as missing
Hi!
On Sun, 2013-06-02 at 10:55:34 +0200, Johannes Schauer wrote:
Package: dpkg-dev
Version: 1.16.10
Severity: normal
User: crossbu...@debian.org
Usertags: cross
There is an inconsistency between `dpkg-checkbuilddeps -a${arch}` and
`apt-get build-dep -a${arch}` behavior. Here we test on the source
package bash which Build-Depends on autoconf which is Multi-Arch: none.
$ dpkg-checkbuilddeps -aarmel
dpkg-checkbuilddeps: Unmet build dependencies: libncurses5-dev sharutils time
$ apt-get build-dep -aarmel bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Build-Depends dependency for bash cannot be satisfied because the package
autoconf cannot be found
The package autoconf is not listed as an unmet build dependency by
dpkg-checkbuilddeps. Apt-get lists it as being unsatisfiable. It is my
understanding that the apt behavior is the correct one as autoconf is
Multi-Arch: none and can therefore not be used to satisfy the cross
build dependencies of bash. Therefore, autoconf should also appear in
the list of unmet build dependencies as given by dpkg-checkbuilddeps.
autoconf is arch:all, so I don't see any reason why it should not be
able to satisfy the Build-Depends. The reason this does not apply to
Depends, is to try to avoid switching architectures in dependency
chains, as in «pkg-a:arch-a → pkg-b:all → pkg-c:arch-c». But arguably
this might not have been a very good idea after all, given that I think
that kind of dependency chain is IMO legitimate for arch:all packages,
OTOH one reason I didn't have much of a problem with that is because
we can always relax that restriction at any later point (and we
probably should).
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710769: dpkg-checkbuilddeps: unsatisfyable Multi-Arch: none cross build dependencies not listed as missing
Hi Guillem, Quoting Guillem Jover (2013-06-02 16:45:04) autoconf is arch:all, so I don't see any reason why it should not be able to satisfy the Build-Depends. In practice, autoconf does indeed satisfy this Build-Depends of bash and in general should also be marked M-A:foreign. Another bug about that has to be filed for that. The reason this does not apply to Depends, is to try to avoid switching architectures in dependency chains, as in «pkg-a:arch-a → pkg-b:all → pkg-c:arch-c». Yes, but I can't find this different treatment of Depends and Build-Depends in the multiarch spec. But arguably this might not have been a very good idea after all, given that I think that kind of dependency chain is IMO legitimate for arch:all packages, OTOH one reason I didn't have much of a problem with that is because we can always relax that restriction at any later point (and we probably should). The question whether arch:all packages should implicitly be marked m-a:foreign came up a number of times so far. For example bug#666772 for apt. Right now, dpkg and apt behave differently so at least one has to be wrong. cheers, josch -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709064: dpkg: some packages missing metainformation after upgrading dpkg (squeeze-wheezy)
Hi Raphaël, On Wed, May 22, 2013 at 04:13:32PM +0200, Raphael Hertzog wrote: Somehow it means that you have /var/lib/dpkg/info/format with a content of 1 when you shouldn't have it yet (you certainly shouldn't have it before you upgraded dpkg). thanks, that indeed was the culprit. This is a virtual environment that has a web gui allowing to install so called application overlays. When used they drop /var/lib/dpkg/info/format into an debian 6 system, doh. Obviously mis-configured - so: sorry for bothering you with this issue. Probably it would be wise to check for the existence of /var/lib/dpkg/info/format when it's not expected to exist and just ignore it or print a warning message. OTOH, this may not happen that often... This bug can be closed now. cheers Hans-Jürgen -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
