FOSDEM: Multiarch on Debian and Ubuntu

The slides are here: http://wookware.org/talks/ (the ELC version given 10 days later has marginally improved slides)

Multiarch does make crossbuilding (on Debian/Ubuntu) much easier in several ways. I cover this in the talk, but to save you watch me blither for 40 mins I'll write it down here.

1) Cross-dependencies.
There has been no proper solution to this in Debian to date, The closest were xapt (which simply installed every dependency in the system twice, once for BUILD arch and once for HOST arch), and xdeb which has a big list of heuristics for package-names that should be cross-installed and library packages which aren't named lib-something, etc). Both of these are pretty cranky, an the huge pile of dpkg-crossed 'local' packages caused upgradeability problems too.

Because multiarch specifies whether things are co-installable (and only satisfy dependencies within an architecture) - (i.e are like libraries) or whether they are not co-installable, and satisfy deps across arches (i.e are like tools), this info provides a very good mapping to whether to install a BUILD arch of HOST arch version of a build-dependency, and there is a syntax to express the exceptions. So suddenly cross-build-deps is a properly defined, deterministic thing that just falls out of the packaging and tools.
apt-get -a<arch> build-dep <package> should install the build tool packages, and cross-library/header packages for the build.

2) Libraries and headers now have a canonical path that doesn't change between build time, run time and install time. Because of this the whole cmake/autoconf/libtool/--libdir shenanigins gets a lots simpler. Files have a path - use it. architecture dependent files have an architecture qualified path. It's beatiful in comparison to what went before.

3) Its easy to install runtimes of a different arch in the system (and their dependencies) and thus (if you have CPU or emulation support) expect them to run, so wrong-arch scripts run at build-time can just work, or you can do your builds as fake-native where a lot of the tools have been replaced by BUILD arch ones. None of this is new (see scratchbox, scratchbox2, OBS), but it all gets a whole lot more orthogonal, which ought to make it a lot easier to use and maintain. Using multiarch for OBS or scratchbox-style not-really-cross building is currently pretty-much untested, so this is my enthusiasm showing through to some degree, but I don't see why it won't work.

Yes, I agree, packages still need to be constructed properly so that can cross correctly, and preferably without running any wrong-arch binaries (The case where you simply don't _have_ qemu support for the HOST arch, so all qemu bodging is cheating, is still very important), but the whole multiarch co-installation infrastructure and canonical pathnames gives us a lot more than just less hassle from RPATH (Debian removes RPATH in almost all cases anyway becauase it's wrong and bad for almost everything except plugins)

I've set up a multiarch cross buildd in order to track the current state of play in terms of what actually works (not a huge amount right now, but I expect that to improve quite rapdily) here:
http://people.linaro.org/~wookey/buildd/