Hello, Following my earlier mail, I'm sending two patches which describe how I see the potential of introducing explicit multilib flags.
The idea is that each arch has its own ABI_<arch> USE_EXPAND, specifying the multilib ABIs for choice. For example, x86 has ABI_X86="32 64". All of those USE_EXPANDs are hidden (using USE_EXPAND_HIDDEN) in the base profile, and all of their flags are masked. In the proper multilib profiles, e.g. the amd64 multilib profile, the relevant USE_EXPAND is removed from USE_EXPAND_HIDDEN, the flags are unmasked and the default ABI flag is use.forced. The eclass exports *all* possible ABIs for all arches in IUSE (due to the necessity of constant metadata). However, it checks only the flags relevant to the arch (avoids wasting time) and when no flags are set (e.g. non-multilib system) does a non-multilib build. The use.force default ABI means that for a typical user the native build is forced and therefore regular package dependencies are correct. The user is allowed to disable it in his own profile but he does that on his own responsibility. For multilib or non-native builds, a proper USE dependencies need be used. Multilib builds take [${MULTILIB_USEDEP}] for them; the Skype example mentioned by aballier would use [abi_x86_32]. I think those are all the important ideas. The patches shall be considered mostly proof-of-concept, and I'm awaiting further discussion on the topic. If anyone is interested in testing the multilib work of mine (which doesn't use the new flags yet, just the profile-forced 'multilib' flag), I have converted the live ebuilds corresponding to packages from emul-linux-x86-xlibs. The packages can be found in the x11 overlay, 'multilib' branch. $ layman -a x11 $ ( cd /var/lib/layman/x11; git checkout multilib ) $ diffmask -a libX11 # yep, X11 live ebuilds are package.masked $ emerge -v emul-linux-x86-xlibs For easier testing, there's media-libs/libtxc_dxtn in the gx86 tree. But it's nothing really special to see, it doesn't even have dependencies to prove the major points.