| 1 |
Michał Górny schrieb: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> With the introduction of support for x32 ABI it has become necessary to |
| 5 |
> enhance the multilib-build eclass with some kind of support for |
| 6 |
> specifying the supported/unsupported ABIs. |
| 7 |
> |
| 8 |
> In this particular context, tetromino has noted that many packages |
| 9 |
> don't support the x32 ABI. From the ones currently using the eclass, |
| 10 |
> the one is app-emulation/wine. |
| 11 |
> |
| 12 |
> I would like to enhance the eclass with the ability to specify |
| 13 |
> supported and unsupported ABIs. For that reason, I'd like to gather |
| 14 |
> your opinion on what would be the best solution. Preferably, I'd see |
| 15 |
> one that could work both for the eclass and multilib-portage so that we |
| 16 |
> wouldn't need to duplicate the same information. |
| 17 |
> |
| 18 |
> |
| 19 |
> 1) opt-in or opt-out? |
| 20 |
> |
| 21 |
> So far, the multilib-capable packages did get support for all multilib |
| 22 |
> ABIs on given architecture enabled (assuming that the package is |
| 23 |
> keyworded for the arch). |
| 24 |
> |
| 25 |
> As a next step from that, I think an opt-out solution be the simplest |
| 26 |
> and most consistent one. In this particular context: |
| 27 |
> |
| 28 |
> MULTILIB_RESTRICT_ABIS=( ... ) |
| 29 |
> |
| 30 |
> which would be an optional variable disabling support for problematic |
| 31 |
> ABIs in the packages which need it. |
| 32 |
|
| 33 |
+1 for this one, better disable support for some packages with reported |
| 34 |
issues then having to update all packages, when an ABI is added. |
| 35 |
|
| 36 |
> |
| 37 |
> |
| 38 |
> An alternative solution would be an opt-in like in python-r1: |
| 39 |
> |
| 40 |
> MULTILIB_COMPAT=( ... ) |
| 41 |
> |
| 42 |
> but so far, that would mean that all current packages will have to be |
| 43 |
> updated to list the currently supported ABIs. And it all sucks a bit |
| 44 |
> due to the gray zone between amd64/x86 keyword and ABIs. |
| 45 |
> |
| 46 |
> |
| 47 |
> And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of |
| 48 |
> opt-in and opt-out which is just awful. |
| 49 |
> |
| 50 |
> |
| 51 |
> |
| 52 |
> 2) USE flag names or ABI names? |
| 53 |
> |
| 54 |
> Next thing to decide would be: whether the restrict should specify USE |
| 55 |
> flag names (like the eclass solution) or ABI names (like |
| 56 |
> portage-multilib and profiles). |
| 57 |
> |
| 58 |
> The advantage of USE flags is that they are guaranteed to be unique |
| 59 |
> and clear. As in, two arches won't ever have the same USE flag for ABI |
| 60 |
> with the same name. |
| 61 |
> |
| 62 |
> MULTILIB_RESTRICT_ABIS=( abi_x86_x32 ) |
| 63 |
> |
| 64 |
> The advantage of ABI names is that multilib-portage is aware of them. |
| 65 |
> So, it's mostly about supporting a poor choice done without consulting |
| 66 |
> other developers. |
| 67 |
> |
| 68 |
> MULTILIB_RESTRICT_ABIS=( x32 ) |
| 69 |
> |
| 70 |
> The problem with that is that a new arch can define an ABI with exactly |
| 71 |
> the same name (since all ABI variables are profile-local). In that |
| 72 |
> case, the restriction will unexpectedly apply to that arch. |
| 73 |
> |
| 74 |
> |
| 75 |
> By the way, maybe we should move the flag -> ABI mapping from |
| 76 |
> the eclass to some global location in profiles? That would make it |
| 77 |
> possible to use the global flags from multilib-portage as well. |
| 78 |
> |
| 79 |
> What are your thoughts? |
| 80 |
> |
| 81 |
|
| 82 |
Once the eclass has per-ABI header and binaries support, i would see |
| 83 |
multilib-portage as fallback option for packages/arches, which dont yet |
| 84 |
have multilib support via eclass. So i am ok with the USE flag names. |
| 85 |
|
| 86 |
-- |
| 87 |
|
| 88 |
Thomas Sachau |
| 89 |
Gentoo Linux Developer |
Archives