1 |
On Sun, 3 Mar 2013 00:02:30 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hello, |
5 |
> |
6 |
> With the introduction of support for x32 ABI it has become necessary |
7 |
> to enhance the multilib-build eclass with some kind of support for |
8 |
> specifying the supported/unsupported ABIs. |
9 |
> |
10 |
> In this particular context, tetromino has noted that many packages |
11 |
> don't support the x32 ABI. From the ones currently using the eclass, |
12 |
> the one is app-emulation/wine. |
13 |
> |
14 |
> I would like to enhance the eclass with the ability to specify |
15 |
> supported and unsupported ABIs. For that reason, I'd like to gather |
16 |
> your opinion on what would be the best solution. Preferably, I'd see |
17 |
> one that could work both for the eclass and multilib-portage so that |
18 |
> we wouldn't need to duplicate the same information. |
19 |
> |
20 |
> |
21 |
> 1) opt-in or opt-out? |
22 |
> |
23 |
> So far, the multilib-capable packages did get support for all multilib |
24 |
> ABIs on given architecture enabled (assuming that the package is |
25 |
> keyworded for the arch). |
26 |
> |
27 |
> As a next step from that, I think an opt-out solution be the simplest |
28 |
> and most consistent one. In this particular context: |
29 |
> |
30 |
> MULTILIB_RESTRICT_ABIS=( ... ) |
31 |
> |
32 |
> which would be an optional variable disabling support for problematic |
33 |
> ABIs in the packages which need it. |
34 |
> |
35 |
> |
36 |
> An alternative solution would be an opt-in like in python-r1: |
37 |
> |
38 |
> MULTILIB_COMPAT=( ... ) |
39 |
> |
40 |
> but so far, that would mean that all current packages will have to be |
41 |
> updated to list the currently supported ABIs. And it all sucks a bit |
42 |
> due to the gray zone between amd64/x86 keyword and ABIs. |
43 |
> |
44 |
> |
45 |
> And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of |
46 |
> opt-in and opt-out which is just awful. |
47 |
|
48 |
|
49 |
I'd go for opt-out (MULTILIB_RESTRICT_ABIS); Ideally we'd want all |
50 |
packages to support all abis, so what we should aim at is building |
51 |
for every abi. Also, opt-in has the big disadvantage that introducing a |
52 |
new abi requires a lot of tree-wide changes, which we tried to avoid |
53 |
since the beginning. |
54 |
|
55 |
|
56 |
> 2) USE flag names or ABI names? |
57 |
> |
58 |
> Next thing to decide would be: whether the restrict should specify USE |
59 |
> flag names (like the eclass solution) or ABI names (like |
60 |
> portage-multilib and profiles). |
61 |
> |
62 |
> The advantage of USE flags is that they are guaranteed to be unique |
63 |
> and clear. As in, two arches won't ever have the same USE flag for ABI |
64 |
> with the same name. |
65 |
> |
66 |
> MULTILIB_RESTRICT_ABIS=( abi_x86_x32 ) |
67 |
> |
68 |
> The advantage of ABI names is that multilib-portage is aware of them. |
69 |
> So, it's mostly about supporting a poor choice done without consulting |
70 |
> other developers. |
71 |
> |
72 |
> MULTILIB_RESTRICT_ABIS=( x32 ) |
73 |
> |
74 |
> The problem with that is that a new arch can define an ABI with |
75 |
> exactly the same name (since all ABI variables are profile-local). In |
76 |
> that case, the restriction will unexpectedly apply to that arch. |
77 |
> |
78 |
> |
79 |
> By the way, maybe we should move the flag -> ABI mapping from |
80 |
> the eclass to some global location in profiles? That would make it |
81 |
> possible to use the global flags from multilib-portage as well. |
82 |
> |
83 |
> What are your thoughts? |
84 |
|
85 |
I'd prefer the useflag names for the sake of unicity, but I'm not sure |
86 |
I understand why and how multilib-portage needs it. |
87 |
What will multilib-portage uses it for ? If that's to gather and use |
88 |
its information to restrict some ABIs, then I assume you will have |
89 |
something like 'if multilib-portage then dont do anything multilib' in |
90 |
the eclass; well, you can very well export a variable translating the |
91 |
useflag names to abi names that multilib-portage can use too. I'm not |
92 |
sure you need the mapping on the profiles. |
93 |
|
94 |
A. |