= 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 }}} 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: DebianBug: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: * http://bootstrap.debian.net/co_ma_same.html * http://bootstrap.debian.net/foreign_install.html = 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 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 [[https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages|'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 multiarch bts user crossbuild@debian.org , usertags 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)