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
signature.asc
Description: PGP signature
