I'm curious how stable and seamless multiarch has become with respect to using the current workarounds with amd64. The project began 2 years ago (?) with not much documentation about it existing today. Does anyone have experience to share?

What kind of "workaround" are you referring to?

I don't have any Debian experience but I've been using x86_64 for years and my 64 bit distribution is multiarch. The 32-bit and 64-bit libraries are segregated and the package system offers 32-bit versions of many of the applications and libraries so you have a choice on what to use. Some very common packages such as Open Office may be only available for 32 bit, so every 64 bit distro has been multiarch to some extent, but their approach may be different.

My distro installed the 32-bit version of Firefox until recent versions to prevent problems with a lack of 64-bit plugins.

AFAIK, there isn't that much to document except for the tool chain and process of developing for 32-bit on a x86_64 system. From a non-developer perspective, except for a couple of plug-ins its been a non-issue.

The 2 workarounds are installing a 32bit chroot or the ia32-libs common library package. This link http://lwn.net/Articles/184092/ can explain the problem better than I can. There is a comment posted further down explaining why rpm is/was not true multiarch.

Thank you for that article. It is food for thought. A package system using /usr/local/ as the base for libraries on the system is not a good idea IMHO. The purpose of /usr/local/ is a place for you to install packages from source (not from your distro repo) and have it protected during an upgrade, reinstallation or from your package system. The package system is forbidden from installing files there, period.

It does make sense using /usr/local/ as the prefix for packages you build from source (that aren't the source packages for your distro). You have the freedom to use /lib & /lib32 instead if that makes more sense to you or /lib32 & /lib64 or have /usr/local/32bit/ and /usr/local/64bit/ prefix.

The /opt/ directory is supposed to be for optional items and tend to be used for large optional sub-systems like a new version of KDE, Java or Open Office, with each in it's own subdirectory. However, using /opt for smaller 32 bit versions on a 64 bit system is not as objectionable as re-purposing /usr/local/ IMHO.

I think that they would have used /lib and /lib32 except for the fact that people might install older 32 bit packages or from source. Even if a new package system will use /lib/ & /lib32 or /lib32 & /lib64, it will be common for people to build a package from source using "./configure && make && make install". If configure & make prepares and builds a 32 bit install then you will still have this problem.

I'm also worried about having a different solution causing too much fragmentation in Linux standards. Use /lib64 on RPM systems. Use /usr/local/lib32 for Debian, but you will find older packages using /lib/ instead. Also look in /opt/lib32 and /opt/<packagename>/lib/, unless the package normally installs to /opt, in which chase look in /opt/32bit/<packagename>/ or /opt/<packagename>/lib32. Add the lib64 variant to the above and you get the idea.i

I just had a thought. You've heard about the petaflop computer that was just built. What do they do? They have both Opterons and Cell processors running at the same time on each and every blade. Programs written specifically for it may have binaries and libraries for both processors. In other words it is a hybrid architecture rather than a biarch architecture.

In the future, the CPUs in our computers will contain a mixture of CPU/GPU architectures on the same chip. I think that rules out the chroot workaround.

Me too and that's seems to be the crux of the problem. Multiarch isn't just a better way of doing 32-bit x86 on amd64, but also about mixing other cpu architectures like sparc or ppc. It adds a lot more complexity but it seems like this is where linux is going, whether it's debian or redhat based, and the current way of doing 32-bit on 64-bit will probably go by the wayside especially if changes are made to the package managers. Thanks for your input, I think this is intriguing too.