1 |
On 03/31/2014 06:16 PM, Micha³ Górny wrote: |
2 |
> Hello, all. |
3 |
> |
4 |
> The late multilib ppc issues made me re-check our stable masks on |
5 |
> abi_x86_* flags and, honestly, I'm not sure if we're doing things |
6 |
> the right way. First, a quick summary. |
7 |
> |
8 |
> |
9 |
> Let's consider dev-libs/elfutils that has a dependency |
10 |
> on app-arch/bzip2. If we're building 32-bit elfutils, it needs 32-bit |
11 |
> libbz2. This is enforced through a dep in form of: |
12 |
> |
13 |
> app-arch/bzip2[${MULTILIB_USEDEP}] |
14 |
> |
15 |
> that gets expanded into: |
16 |
> |
17 |
> app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,...,abi_mips_o32(-)?,...] |
18 |
> |
19 |
> which means that any of the ABI_* flags that gets enabled on elfutils, |
20 |
> needs to be enabled on bzip2 as well. Of course, some of use.forcing |
21 |
> and masking gets applied here but that doesn't really matter. |
22 |
> |
23 |
> |
24 |
> Now, since we're pretty much converting a lot of different packages, |
25 |
> some of them are eligible for stabilization earlier than the others. |
26 |
> However, the extra MULTILIB_USEDEPs enforce stabilizing multilib |
27 |
> dependencies before the actual packages which made a few developers |
28 |
> unhappy. |
29 |
> |
30 |
> That's why we decided to stable-mask the flags on affected packages. |
31 |
> Since the flags are masked on stable, people can stabilize packages |
32 |
> independently of whether their converted deps are stable or not. We |
33 |
> will be worrying about that consistency once we decide to unmask |
34 |
> the flags. |
35 |
> |
36 |
> The extra advantage of that is that we can avoid pushing stable users |
37 |
> into the mess involved with partial conversion of emul-linux. The idea |
38 |
> is pretty simple: we keep emul-linux for stable, and once everything is |
39 |
> ready, we stable-unmask the flags and let stable users grok multilib. |
40 |
> |
41 |
> |
42 |
> Now, to the problem. Currently we're just stable-masking abi_x86_32 |
43 |
> on amd64. This serves the latter purpose well and seems to work for the |
44 |
> former. This is probably because the remaining flag is use.forced |
45 |
> (abi_x86_64 on amd64, and abi_x86_32 on x86) which seems to add it to |
46 |
> implicit IUSE somehow. |
47 |
> |
48 |
> floppym has done some research w/ stable elfutils and no stable |
49 |
> converted bzip2. It seems that if abi_x86_32 is stable.use.masked |
50 |
> and abi_x86_64 is use.forced, repoman groks it. However, if we remove |
51 |
> abi_x86_64 from use.force, it properly reports flag mismatch error |
52 |
> (since no stable bzip2 has IUSE=abi_x86_64). |
53 |
> |
54 |
> Now, I honestly have no idea if this implicit use.force behavior is |
55 |
> PMS-y or not, and how other PMs handle it. I can't find something like |
56 |
> this in the PMS but that doc is horribly hard to cross-reference, so I |
57 |
> might be missing something. I'd appreciate if someone could help me |
58 |
> with that. |
59 |
> |
60 |
> |
61 |
> That said, I have an alternate idea inspired by the ppc breakage. I'm |
62 |
> thinking of replacing the amd64 abi_x86_32 mask with a global stable |
63 |
> mask of all abi_*_* flags on the relevant packages. |
64 |
I'm not sure exactly what you mean here --- where/how does this global |
65 |
stable masking happen? Right now you have a bunch of maskings of |
66 |
abi_x86_32 on various packages in arch/amd64/package.use.stable.mask but |
67 |
not on any other arches where you just have the use.mask/use.force |
68 |
combination. Are you going to migrate the amd64 file to other multilib |
69 |
arches and mask non-native abis? Like on mips64el/multilib/n32 would |
70 |
you be masking abi_mips_o32 and abi_mips_n64 for all those packages? |
71 |
|
72 |
> |
73 |
> Differences: |
74 |
> |
75 |
> 1) old solution: native flag is forced, other flags are masked. |
76 |
> new solution: all flags are masked. |
77 |
> |
78 |
> 2) old solution: we need to replicate the masks properly for different |
79 |
> arches/profiles. |
80 |
> new solution: we can keep a single mask for all arches. |
81 |
|
82 |
This sounds like a partial answer to my above question. |
83 |
|
84 |
> |
85 |
> 3) old solution: MULTILIB_USEDEP magically works (w/ portage at least). |
86 |
> new solution: since all flags are disabled, MULTILIB_USEDEP |
87 |
> is a no-op and old packages match correctly. |
88 |
> |
89 |
> 4) old solution: forced native flag runs the native build. |
90 |
> new solution: fallback code runs the native build (since no flags |
91 |
> are enabled). |
92 |
> |
93 |
> |
94 |
> Your thoughts? |
95 |
> |
96 |
|
97 |
How does this "go live" once these flags are enabled? Do you just |
98 |
remove the global mask all at once? That sounds a bit scarier than just |
99 |
removing the masks one package + deps at a time. (Maybe a non-question |
100 |
because I'm still now sure how this masking works.) |
101 |
|
102 |
Also, I don't see that it should be an issue, but do you think this |
103 |
might affect catalyst runs --- I have to ask because |
104 |
repairing/reconfiguring seeds is a lot of work. |
105 |
|
106 |
-- |
107 |
Anthony G. Basile, Ph.D. |
108 |
Gentoo Linux Developer [Hardened] |
109 |
E-Mail : blueness@g.o |
110 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
111 |
GnuPG ID : F52D4BBA |