This page collects current issues about multiarch that people should be aware of, or need further discussion/work

Multiarching libtool

See discussion in

libtool largely functions as an MA:foreign tool, but it also has arch-independent parts. Thus it is not clear how best to multiarchify it. Just setting it to be MA: foreign (as has been done in Ubuntu quantal onwards) works quite well in practice but is not strictly speaking correct.

These are the options: 1) Split the arch all part out in libtool-dev. Have libtool Depend

2) Keep the arch all in libtool, but split the binary in

3) Use Multi-arch: allowed 4) Drop the /usr/bin/libtool and change it to an arch all package

Multiarching perl

This has it's own page:

Perl highlights a gap in the existing multiarch spec, showing that the design assumes C-library style dependencies where a dependency is either arch-specific, or it is not, and an arch-independent dependency 'breaks the chain' such that things that it in turn depends on, are arch-independent. Unfortunately this does not work for perl modules, where and arch-dependent perl module can depend on an arch-independent perl modules which can depend on an arch-dependent perl module, where the last module needs to match the arch of the first module. Nothing in the multiarch spec 'passes down' the required architecture to the bottom of the chain (without making every arch:all perl module arch:any, which seems a very poor solution). A mechanism to express this type of transitive architecture-dependency is needed.

See for expansion-on/discussion-of this issue.

Testing for multiarch support in dpkg

If you need to support releases older than Debian stable or Ubuntu precise in tools that use dpkg internally (and use the multiarch features) then you need to take care about version numbers. MultiArch support in dpkg and apt appeared at different times in Debian and Ubuntu. For example, the debian dpkg version does not allow the multiarch configuration variable to be set, whereas the Ubuntu version and versions >= 1.16.0~ubuntu4 do allow the variable to be set. Until these versions have been safely superceeded everywhere you need to check functionality, rather than versions.

With incompatible versions, dpkg fails entirely:

$ cat /etc/dpkg/dpkg.cfg.d/test 
foreign-architecture armel

$ dpkg -l dpkg
dpkg: error: configuration error: /etc/dpkg/dpkg.cfg.d/test:1: unknown option 'foreign-architecture'
$ sudo rm /etc/dpkg/dpkg.cfg.d/test 
$ dpkg -l dpkg
ii  dpkg                                              Debian package management system

This means that tools wanting to implement multiarch support in chroots etc. will need to carefully check dpkg support which will involve checking versions based on the value retrieved from lsb_release -is or use dpkg-vendor. lsb_release is installed by default in Ubuntu, so if it is not present, tools can decide to assume Debian and then check the dpkg version appropriately.

Issues and confusion with native vs cross builds

MultiArch is independent of native or cross-building. Multiarched packages are to be built natively, as usual, using the new paths internally and for the dependencies and will support installing natively built packages from multiple architectures side-by-side.

MultiArch is related to cross-building issues and is makes cross-building a lot easier because tools like apt can calculate the dependency chains for installing cross dependencies. A cross-built multiarched package should come out exactly the same as a native-built one, using the same internal paths.

Implementing MultiArch does not need cross-build issues to be fixed first. They are independent; indeed, in order to provide a cross-building method on a MultiArch base, a lot more packages need to be converted to MultiArch. The toolchains and tools used in cross-building need a critical mass of packages to be working in MultiArch before they can be used for real work.

Please do not confuse cross-building (supplying the --host argument to ./configure) with MultiArch (changing the paths in .install files etc.) - the two impact on each other but they are NOT the same problem.

Cross-building in multiarch will just do the right thing with regard to the paths - it was dpkg-cross which was doing the right thing in the wrong way and using different paths just because it got there first.

See also: