Paul Wise called attention recently to the fact that there's renewed activity around multiarch in the face of the squeeze release. Although I fervently wish we could have gotten multiarch support into squeeze, it's better late than never; and real progress is being made now, thanks mostly to the efforts of wonderful package management experts like Raphael Hertzog, Guillem Jover, and David Kalnischkies.

Don't believe it's finally coming? Here's some output from my amd64 multiarch chroot:

$ dpkg -l '*:i386'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  gcc-4.5-base   4.5.2-3ubuntu2 The GNU Compiler Collection (base package)
ii  libc6          2.13-0ubuntu1+ Embedded GNU C Library: Shared libraries
ii  libdb4.8       4.8.30-5multia Berkeley v4.8 Database Libraries [runtime]
ii  libgcc1        1:4.5.2-3ubunt GCC support library
in  libpam-modules <none>         (no description available)
ii  libpam0g       1.1.2-2ubuntu1 Pluggable Authentication Modules library
ii  libselinux1    2.0.96-1multia SELinux runtime shared libraries
ii  libstdc++6     4.5.2-3ubuntu2 The GNU Standard C++ Library v3
iU  libuuid1       2.17.2-9.1ubun Universally Unique ID library
ii  selinux-utils  2.0.96-1multia SELinux utility programs
ii  zlib1g         1:1.2.3.4.dfsg compression library - runtime

If you're as excited about this making its way into Debian as I am, you might be wondering what you can do to help. That's great, because I'd love to tell you! Perhaps you happen to maintain a package that provides executables; and perhaps other packages depend on your package exclusively to use those executables; and perhaps some of those packages depending on your package are shared libraries.

If all of the above is true, please consider declaring this package to be Multi-Arch: foreign as defined here.

Note: it is very important that you not use this on any package that will provide architecture-dependent interfaces to its reverse-dependencies. So if you're shipping both shared libraries and executables in the same binary package, don't do this.

But if your package does fit this description, this is one part of multiarch that you can safely start implementing today. This will go a long way towards getting the system ready to handle multiarch libraries when they land.

My own efforts to help with getting Multi-Arch: foreign packages documented in the archive are trackable here.