[gentoo-dev] [RFC] Initial proof-of-concept for explicit x86 multilib flags

[Michał Górny]

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.