Multiarch cross-dependency bugs
apt can now install cross build-dependencies - i.e the build-dependencies needed for cross-building, as well as the normal native build-dependencies
just do:
apt-get build-dep -a <arch> <package>
e.g
apt-get build-dep -a armel atk1.0
In order for this to work, packages must be correctly marked Multi-Arch: foreign or Multi-Arch: same (or occasionally Multi-Arch: allowed).
In simple terms any architecture-independent tool or package should be marked Multi-Arch: foreign. This is anything which is used in the build and will produce the same output whatever architecture version of it is run (debhelper, make, gettext, pkg-config).
Whilst many packages do now have the Multi-Arch: foreign header, there are still plenty that don't, but should, so apt tries to install the DEB_HOST_ARCH version instead of the DEB_BUILD_ARCH one, and finds it can't because it can't install both the existing build architecture version and the host architecture version at the same time.
Generic apt fix
This bug describes an apt modification which means that Multi-Arch: foreign can be made implicit for Architecture: all packages in Build-deps: 666772.
This saves adding the explicit header to many packages, and has been used in Ubuntu as it is a quick way to make more build-deps multiarch-installable. However it has been rejected for Debian as not being rigorous enough, nor correct in all cases. In debian each package needs to be marked MA:foreign explicitly.
Lists of packages with issues
bootstrap.debian.net provides (weekly updated) lists of packages which need multiarch attention:
Typical error messages
This is the sort of thing you get on running apt-get build-dep -a
Cross-deps: Running apt-get -aarmel build-dep dash Reading package lists... Building dependency tree... Reading state information... The following packages have unmet dependencies: po-debconf : Depends: gettext (>= 0.16) but it is not going to be installed Depends: intltool-debian (>= 0.34.2+20060512) but it is not going to be installed sharutils:armel : Depends: libc6:armel (>= 2.4) but it is not going to be installed Depends: libgcc1:armel (>= 1:4.4.0) but it is not going to be installed E: Build-dependencies for dash could not be satisfied. Failed to get cross build-deps
So in this case the package to look at is sharutils. This is probably arch-independent in its action in which case it should be marked 'Multi-Arch: foreign' at which point apt would try to install sharutils instead of sharutils:armel
You will see various forms of complaint from apt:
- "E: Build-Depends dependency for dbus-glib cannot be satisfied because package gtk-doc-tools has no candidate version"
In this latter case gtk-doc-tools is probably the package that needs fixing.
- gettext:armel : Depends: gettext-base:armel but it is not going to be installed
In this case gettext needs fixing first. gettext-base may also need fixing
When you have fixed one of these, often apt-get build-dep -a still fails as apt simply complains about the next package. It may take several iterations to get all the build-deps correctly annotated.
Sometimes things are more complicated than this and the package in question is not a direct build-dep but something one of the build-deps depends on (eg. -common data). You will need to modify the bugrep to make sense in these cases.
all vs any -dev packages
Sometimes the issue is transitive architecture dependencies.
Consider libdb-dev. This is a trivial package which simply selects which real version of libdb should currently be depended on by default. e.g. libdb4.8-dev. A package build-depending on libdb-dev wants the HOST_ARCH version of the real libdb4.8-dev. i.e libdb4.8-dev:armel if building for armel.
Until multiarch libdb-dev would be Architecture: all because there was nothing arch-specific about it. But now it needs to be Architecture: any so that that arch can be 'passed on' to get the correct arch of libdb4.8-dev.
i.e $package:armel ---build-depends---> libdb-dev:armel ---depends---> libdb4.8-dev:armel
This wouldn't work if libdb-dev was _all.
So sometimes the correct fix is to change the architecture of the package from 'all to 'any'.
When shouldn't I add M-A: foreign?
When the package is not arch-independent in its effects, i.e if you run the wrong-arch version it will operate on the wrong files or produce the wrong output. A common example is gobject-introspection. Whether something should be M-A: foreign does not depend on the architecture of the package itself (all, any), but on what it does.
Also there are packages where the dependency may be either same-arch or cross-arch. These are the cases that need to be marked M-A: allowed. There are very few of these. Ask on #multiarch on OFTC if you are unsure.
What to change
Simply add
Multi-Arch: foreign
to the control file.
By convention it goes after the various Depends/Replaces/Recommends headers and before the Description.
Here is a typical patch:
--- asciidoc-8.6.6/debian/control 2012-03-06 19:14:19.000000000 +0000 +++ asciidoc-8.6.6.new/debian/control 2012-03-05 18:07:24.000000000 +0000 @@ -14,6 +14,7 @@ Depends: python (>= 2.4), ${misc:Depends}, ${python:Depends} Recommends: docbook-utils, xmlto, dblatex, libxml2-utils Suggests: vim-addon-manager, source-highlight +Multi-Arch: foreign Description: Highly configurable text format for writing documentation AsciiDoc is a text document format for writing articles, books, manuals and UNIX man pages. AsciiDoc files can be translated to HTML (with or without
Bug Report Template
Title: Add multiarch metadata to $package
Description/Body text:
We are working on getting multiarch metadata correct throught the archive. This package needs to be marked 'Multi-Arch: foreign' for dependencies and build-depencies to work correctly in all cases.
Any package 'X' build-depending on $package cannot be cross-built because apt-get build-dep -a<arch> cannot satisfy X's build-dependencies until
Multi-Arch: foreign
is added to $packages's control file, to indicate that $package from any available arch will satisfy the dependency.
See http://wiki.debian.org/Multiarch/CrossDependencies and 'Dependencies involving Architecture: all packages' in the Multiarch Spec for further explanation.
Optional extra info to indicate how much a blocker this particular bug is: There are n packages which build-depend on $package in the archive. None of them will be multiarch cross-buildable without this fix.
The bug should be tagged multiarch and cross. In debian that means adding user=multiarch-devel@lists.alioth.debian.org, tag=multiarch user=crossbuild@debian.org, tag=cross
Adding the tags to an existing bugreport using the bts command:
bts user multiarch-devel@lists.alioth.debian.org , usertags <bugnumber> multiarch bts user crossbuild@debian.org , usertags <bugnumber> cross
Details on how to do it: http://wiki.debian.org/bugs.debian.org/usertags
In Ubuntu that means adding the tags 'multiarch' and 'cross' in launchpad
Debian and Ubuntu differences
Currently apt in Ubuntu and apt in Debian have slightly different apt-get build-dep -a behaviour. You are more likely to see these issues in Ubuntu currently (March 2012), but this is a temporary state of affairs - the required metadata rules are exactly the same in all Debian-based distros.
Testing number of packages affected by this build-dep
This is how to get the 'n' for "There are n packages which build-depend on $package in the archive".
grep-dctrl -s Package -F Build-depends,Build-depends-indep $package /var/lib/apt/lists/*Sources
(grep-dctrl is from the dctrl-tools package)