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

[Alexis Ballier <aballier@gentoo.org>]

On Sun, 3 Mar 2013 00:02:30 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> 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.


I'd go for opt-out (MULTILIB_RESTRICT_ABIS); Ideally we'd want all
packages to support all abis, so what we should aim at is building
for every abi. Also, opt-in has the big disadvantage that introducing a
new abi requires a lot of tree-wide changes, which we tried to avoid
since the beginning.


> 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?

I'd prefer the useflag names for the sake of unicity, but I'm not sure
I understand why and how multilib-portage needs it.
What will multilib-portage uses it for ? If that's to gather and use
its  information to restrict some ABIs, then I assume you will have
something like 'if multilib-portage then dont do anything multilib' in
the eclass; well, you can very well export a variable translating the
useflag names to abi names that multilib-portage can use too. I'm not
sure you need the mapping on the profiles.

A.