[gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs

[Michał Górny]

Hello,

With the introduction of support for x32 ABI it has become necessary to
enhance the multilib-build eclass with some kind of support for
specifying the supported/unsupported ABIs.

In this particular context, tetromino has noted that many packages
don't support the x32 ABI. From the ones currently using the eclass,
the one is app-emulation/wine.

I would like to enhance the eclass with the ability to specify
supported and unsupported ABIs. For that reason, I'd like to gather
your opinion on what would be the best solution. Preferably, I'd see
one that could work both for the eclass and multilib-portage so that we
wouldn't need to duplicate the same information.


1) opt-in or opt-out?

So far, the multilib-capable packages did get support for all multilib
ABIs on given architecture enabled (assuming that the package is
keyworded for the arch).

As a next step from that, I think an opt-out solution be the simplest
and most consistent one. In this particular context:

  MULTILIB_RESTRICT_ABIS=( ... )

which would be an optional variable disabling support for problematic
ABIs in the packages which need it.


An alternative solution would be an opt-in like in python-r1:

  MULTILIB_COMPAT=( ... )

but so far, that would mean that all current packages will have to be
updated to list the currently supported ABIs. And it all sucks a bit
due to the gray zone between amd64/x86 keyword and ABIs.


And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of
opt-in and opt-out which is just awful.



2) USE flag names or ABI names?

Next thing to decide would be: whether the restrict should specify USE
flag names (like the eclass solution) or ABI names (like
portage-multilib and profiles).

The advantage of USE flags is that they are guaranteed to be unique
and clear. As in, two arches won't ever have the same USE flag for ABI
with the same name.

  MULTILIB_RESTRICT_ABIS=( abi_x86_x32 )

The advantage of ABI names is that multilib-portage is aware of them.
So, it's mostly about supporting a poor choice done without consulting
other developers.

  MULTILIB_RESTRICT_ABIS=( x32 )

The problem with that is that a new arch can define an ABI with exactly
the same name (since all ABI variables are profile-local). In that
case, the restriction will unexpectedly apply to that arch.


By the way, maybe we should move the flag -> ABI mapping from
the eclass to some global location in profiles? That would make it
possible to use the global flags from multilib-portage as well.

What are your thoughts?

-- 
Best regards,
Michał Górny