Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Hi,
On Sun, Aug 05, 2012 at 01:53:35AM +0200, David Kalnischkies wrote:
> Attached is a diff for bug-class which should ensure that APT chooses
> by default a host-arch packages (and especially a provider from that
> arch) instead of sometimes ending up using build-arch.
Here is an analysis that ran on all source packages of Debian Sid after
having applied the patch of your last email to apt.
Out of 18244 source package in Debian Sid, apt-get and dose3 now only
disagree on 10 remaining packages (actually that number is only true
assuming that apt bug#683917 would also be resolved). 10 Packages are a
small enough number so that each can get a deeper analysis.
You can reproduce my results by creating a Debian Sid chroot as follows:
sudo debootstrap --variant=minbase sid debian-sid-minbase
echo -ne "deb http://ftp.debian.org/debian sid main\ndeb-src http://ftp.debian.org/debian sid main\n" | sudo tee debian-sid-minbase/etc/apt/sources.list
sudo chroot debian-sid-minbase dpkg --add-architecture armel
sudo chroot debian-sid-minbase apt-get update
sudo chroot debian-sid-minbase apt-get --simulate -aarmel build-dep $package
Fails with apt-get
==================
Apt-get cannot satisfy the dependencies of the following source packages
while dose3 can: libcatalyst-actionrole-acl-perl, obex-data-server,
qdox, renattach, trueprint.
libcatalyst-actionrole-acl-perl
-------------------------------
Build-Depends-Indep on libcatalyst-controller-actionrole-perl. Apt-get
says:
libcatalyst-controller-actionrole-perl : Depends: libcatalyst-perl (>= 5.80025) but it is not going to be installed
It probably says that because libcatalyst-perl conflicts with
libcatalyst-controller-actionrole-perl.
But dose3 sees, that libcatalyst-controller-actionrole-perl is also
provided by libcatalyst-perl, so it uses libcatalyst-perl to satisfy the
build depends of the source libcatalyst-controller-actionrole-perl.
obex-data-server
----------------
Build-Depends on libmagickwand-dev (>= 6.0.0) | libgtk2.0-dev.
>From those two choices, apt chooses to install libmagickwand-dev but
fails to do so. Dose3 agrees that libmagickwand-dev is not installable,
therefor it chooses to satisfy the build dependencies for
obex-data-server using libgtk2.0-dev instead. Apt-get on the other hand
doesnt try libgtk2.0-dev and therefor fails.
qdox
----
Was not able to make out what apt-get actually has a problem with.
renattach
---------
Build-Depends on exim4 | mail-transport-agent.
Virtual packages like 'mail-transport-agent:armel' can't be removed
Dose3 on the other hand just satisfies the mail-transport-agent
dependency using xmail and is done with it.
trueprint
---------
Build-Depends on lpr which Depends on netbase.
lpr:armel : Depends: netbase:armel but it is not installable
When trying to install netbase:armel itself, apt-get says:
Package netbase:armel is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
net-tools:armel iputils-tracepath:armel iputils-ping:armel iputils-arping:armel ifupdown:armel update-inetd net-tools
iputils-tracepath iputils-ping iputils-arping ifupdown
Dose3 on the other hand, sees that lpr is also provided by lprng and
uses this package to satisfy the build dependencies of trueprint,
thereby not getting into the netbase problem.
Fail with dose3
===============
Dose3 cannot satisfy the dependencies of the following source packages
while apt-get can: bomberclone, freetalk, garden-of-coloured-lights,
mailsync, worker.
bomberclone
-----------
Build-depends on findutils:armel which clashes with the installed
package findutils:amd64.
Apt-get chooses to just remove findutils:amd64 and replaces it with
findutils:armel. The multiarch cross spec doesnt cover this case so it
is debatable whose behaviour is right.
Maybe the following section of the multiarch spec should apply to the
cross case as well:
> it is assumed that any undeclared dependencies on Essential packages
> on the part of multiarch packages is satisfied by the binaries from
> the native architecture
Therefore, apt-get should not replace findutils:amd64 by findutils:armel
and dose3 should see the findutils:armel dependency satisfied by
findutils:amd64.
But this has to be discussed in another place.
freetalk
--------
Build-Depends on automake1.11 which is a virtual package provided by
automake. Apt get wrongly installs the native version of automake
instead of automake:armel.
garden-of-coloured-lights
-------------------------
Same as with freetalk.
mailsync
--------
Same as with freetalk.
worker
------
Build-Depends on sed:armel, which is essential. So same question as with
bomberclone.
Conclusion
==========
For this bugreport, the issues found with freetalk,
garden-of-coloured-lights, and mailsync seem to be most relevant.
libcatalyst-actionrole-acl-perl, obex-data-server, renattach and
trueprint seem to be situations in which the apt solver fails even
though there exists a solution. But that would be another bugreport.
The results of bomberclone and worker are debatable but I think the idea
of the multiarch spec is, that they should be treated like M-A: foreign
and that therefor a native essential packages satisfies foreign cross
build dependencies?
A bit off-topic
===============
Can I somehow force apt-get to satisfy the build dependencies for a
given source package and not fall back to another? It is really
bothersome to read:
Picking 'kmod' as source package instead of 'module-init-tools'
Why can I not use apt-get to satisfy the build dependencies for
module-init-tools? This effect occurs all over the place and means that
we cannot properly compare the output of apt-get and dose3 on a given
package list. It might mean that there are other packages out there that
dose3 and apt-get agree upon but only because apt-get actually decided
to chose a different source package instead. Because of this issue, the
information that there exist only 10 source packages on which apt-get
and dose3 disagree is very likely to be incorrect.
cheers, josch
Reply to: