As I announced on debian-devel, Guillem Jover uploaded a snapshot of dpkg’s multiarch branch to experimental (version 1.16.2~wipmultiarch). Beware: There will
likely be some small “interface” changes between this version and the version that will be released later in unstable (possibly in the output of dpkg --get-selections, dpkg --list, maybe other commands).
multiarch allows you to install packages from different architectures on the same machine. This can be useful if your computer can run programs from 2 architectures (eg. x86 CPU supporting i386 and amd64), or if you often need to cross-compile software and thus need the libraries of your target architecture.
Test dpkg with multiarch support
If you want to test multiarch support in dpkg, install the package from experimental (apt-get install dpkg/experimental assuming you have experimental in your sources.list).
Then you can add a supplementary architecture to your system by doing sudo dpkg --add-architecture <arch> (e.g. i386 if you are on amd64, and vice-versa). APT will automatically pick up the new architecture and start downloading the Packages file for the new architecture (it uses dpkg --print-foreign-architectures to know about them).
From there on you can install packages from the “foreign” architectures with “apt-get install foo:<arch>“. Many packages will not be installable because some of their dependencies have not yet been updated to work with in a multiarch world (libraries must be installed in a multiarch-compliant path so as to be co-installable, and then marked “Multi-Arch: same“). Other dependencies might need to be marked “Multi-Arch: foreign“. See wiki.debian.org/Multiarch/Implementation for more HOWTO-like explanations.
Now is a good time to see if you can install the foreign packages that you could need in such a setup and to help to convert the required libraries.
You can also read Cyril Brulebois’ article which quickly shows how to hunt for the problematic packages which have not been converted to multiarch (in his sample, “ucf” is not ready. Since it’s an “Architecture: all” package which can run on any architecture, it means that it’s lacking a “Multi-Arch: foreign” field).
Report bugs
If you discover any bug in dpkg’s multiarch implementation, please report it to the Bug Tracking System (against “dpkg” with the version “1.16.2~wipmultiarch”).
If you notice important libraries or packages which are not yet multiarch ready, please open wishlist bug reports requesting the conversion and point the maintainers towards the wiki page linked above. Even better, prepare patches and submit those with your bug reports.
Again, you can follow the lead of Cyril Brulebois who filed 6 bugs!
Review the multiarch implementation
If you’re a C programmer and have some good knowledge of dpkg (or are willing to learn more of it), we would certainly benefit from more eyes reviewing the multiarch branch. If you want to discuss some design issues of the multiarch implementation in dpkg (or have questions related to your review), please get in touch via debian-dpkg@lists.debian.org.
The latest version of the branch is pu/multiarch/master in Guillem’s personal repository. I have my own version of the branch (pu/multiarch/full) which is usually a snapshot of Guillem’s branch with my own submitted fixes.
$ git clone git://git.debian.org/dpkg/dpkg.git $ cd dpkg $ git remote add guillem git://git.hadrons.org/git/debian/dpkg/dpkg.git $ git remote add buxy git://git.debian.org/~hertzog/dpkg.git $ git fetch guillem && git fetch buxy
If you followed the instructions above, the relevant branches are thus guillem/pu/multiarch/master and buxy/pu/multiarch/full. Both branches are regularly rebased on top of master where Guillem merges progressively the commits from the multi-arch branch as his review progresses.
Thank you in advance for your help bringing multiarch in shape for Debian Wheezy,
For the record: aptitude seems to be pretty unhappy about multiarch packages being installed.
Why did the announcement go to debian-devel rather than debian-devel-announce? Seems like d-d-a would help get a wider test audience, which would help eliminate more bugs before the high-impact upload to unstable.
Because I’d rather not use debian-devel-announce for an announce that was not validated by Guillem. And also because I believe that it doesn’t need to be advertised too much before the availability in unstable in case Guillem makes important changes. And I prefer a small set of skilled testers rather than many people who will need support because they played with something that they did not understand…
Just a question of someone who hasn’t fully understood yet, how multiarch is supposed to work – why is it neccessary to specify the supplementary architectures? Isn’t it possible to determine supplementary architectures automatically, e.g. based on current architecture and installed CPU? I’m not even sure it is a good idea to let the user choose supplementary architectures.
dpkg is a low-level tool, it should not do too much automagically… if Debian wants to enable multi-arch automatically for its users, then debian-installer can be modified and/or someone can provide a package which does the required auto-detection and add the architectures via a postinst script for example.
While dpkg is a low-level tool it *does* provide an interface to users and *is* used directly by users. And even low level tools should provide sensible defaults, if possible. I don’t know if it is possible to provide defaults without implementing a complex automagic – thats why I ask.
And btw. I do not consider enabling multiarch and specifying complementary architectures the same task (although in practice it probably is, since you implemented it this way)