Quote Originally Posted by Sonadow View Post
It's totally different from RPM-style multilib.

Fedora (and virtually all RPM-based distributions that have adopted the /usr merge) split libraries into a /usr/lib and a user/lib64, where /usr/lib stores 32bit libraries and a handful of important 64bit libraries. /usr/lib/64 stores the remaining majority of the 64bit libraries.

Before multiarch on Debian was available the Debian way was to have a /lib and /lib32, where /lib stores the 64bit libraries and /lib32 stores the runtime libraries installed by the ia32-libs package (which only contains the most commonly used 32bit runtime libraries, and not the whole set of 32bit libraries).

With multiarch Debian now stores libraries in the /usr/lib/<architecture>/ format so you will get something like this in the root directory:

/usr/lib/ia32(or was it i586, can't remember)/
usr/lib/amd64/
usr/lib/arm/
usr/lib/arm64/

As you can see the very nice thing about Debian's style of multiarch is that there is only one /lib directory at the top level, with all the architectures being separated into their own folder at a lower level. The RPM way of having usr/lib and usr/lib64 was definitely superior to Debian's then non-standard /lib32 and /lib implementation, but the new way Debian handles multiarch in 7.0 is now definitely more elegant than the current /usr/lib and usr/lib64 implementation.

The question is whether the RPM-based distributions will adopt the Debian way of multiarch now. I hope they do, but not holding my breath.
It's /usr/lib/i386-linux-gnu/ and /usr/lib/x86_64-linux-gnu/.
After getting used to it, I quite like it. I really hope Redhat/Suse/Gentoo will also implement it, but I'm not expecting it.