Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: multilib@g.o
Cc: gentoo-dev@l.g.o
Subject: [gentoo-dev] Stable masks on multilib packages
Date: Mon, 31 Mar 2014 22:16:36
Message-Id: 20140401001617.42fdc3bc@pomiot.lan
1 Hello, all.
2
3 The late multilib ppc issues made me re-check our stable masks on
4 abi_x86_* flags and, honestly, I'm not sure if we're doing things
5 the right way. First, a quick summary.
6
7
8 Let's consider dev-libs/elfutils that has a dependency
9 on app-arch/bzip2. If we're building 32-bit elfutils, it needs 32-bit
10 libbz2. This is enforced through a dep in form of:
11
12 app-arch/bzip2[${MULTILIB_USEDEP}]
13
14 that gets expanded into:
15
16 app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,...,abi_mips_o32(-)?,...]
17
18 which means that any of the ABI_* flags that gets enabled on elfutils,
19 needs to be enabled on bzip2 as well. Of course, some of use.forcing
20 and masking gets applied here but that doesn't really matter.
21
22
23 Now, since we're pretty much converting a lot of different packages,
24 some of them are eligible for stabilization earlier than the others.
25 However, the extra MULTILIB_USEDEPs enforce stabilizing multilib
26 dependencies before the actual packages which made a few developers
27 unhappy.
28
29 That's why we decided to stable-mask the flags on affected packages.
30 Since the flags are masked on stable, people can stabilize packages
31 independently of whether their converted deps are stable or not. We
32 will be worrying about that consistency once we decide to unmask
33 the flags.
34
35 The extra advantage of that is that we can avoid pushing stable users
36 into the mess involved with partial conversion of emul-linux. The idea
37 is pretty simple: we keep emul-linux for stable, and once everything is
38 ready, we stable-unmask the flags and let stable users grok multilib.
39
40
41 Now, to the problem. Currently we're just stable-masking abi_x86_32
42 on amd64. This serves the latter purpose well and seems to work for the
43 former. This is probably because the remaining flag is use.forced
44 (abi_x86_64 on amd64, and abi_x86_32 on x86) which seems to add it to
45 implicit IUSE somehow.
46
47 floppym has done some research w/ stable elfutils and no stable
48 converted bzip2. It seems that if abi_x86_32 is stable.use.masked
49 and abi_x86_64 is use.forced, repoman groks it. However, if we remove
50 abi_x86_64 from use.force, it properly reports flag mismatch error
51 (since no stable bzip2 has IUSE=abi_x86_64).
52
53 Now, I honestly have no idea if this implicit use.force behavior is
54 PMS-y or not, and how other PMs handle it. I can't find something like
55 this in the PMS but that doc is horribly hard to cross-reference, so I
56 might be missing something. I'd appreciate if someone could help me
57 with that.
58
59
60 That said, I have an alternate idea inspired by the ppc breakage. I'm
61 thinking of replacing the amd64 abi_x86_32 mask with a global stable
62 mask of all abi_*_* flags on the relevant packages.
63
64 Differences:
65
66 1) old solution: native flag is forced, other flags are masked.
67 new solution: all flags are masked.
68
69 2) old solution: we need to replicate the masks properly for different
70 arches/profiles.
71 new solution: we can keep a single mask for all arches.
72
73 3) old solution: MULTILIB_USEDEP magically works (w/ portage at least).
74 new solution: since all flags are disabled, MULTILIB_USEDEP
75 is a no-op and old packages match correctly.
76
77 4) old solution: forced native flag runs the native build.
78 new solution: fallback code runs the native build (since no flags
79 are enabled).
80
81
82 Your thoughts?
83
84 --
85 Best regards,
86 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Stable masks on multilib packages "Anthony G. Basile" <blueness@g.o>
Re: [gentoo-dev] Stable masks on multilib packages Ben de Groot <yngwin@g.o>
Re: [gentoo-dev] Stable masks on multilib packages Ian Stakenvicius <axs@g.o>
Re: [gentoo-dev] Stable masks on multilib packages "Michał Górny" <mgorny@g.o>