Michał Górny schrieb: > 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.
+1 for this one, better disable support for some packages with reported issues then having to update all packages, when an ABI is added. > > > 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? > Once the eclass has per-ABI header and binaries support, i would see multilib-portage as fallback option for packages/arches, which dont yet have multilib support via eclass. So i am ok with the USE flag names. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
