On 03/31/2014 06:16 PM, Michał Górny wrote:
Hello, all.
The late multilib ppc issues made me re-check our stable masks on
abi_x86_* flags and, honestly, I'm not sure if we're doing things
the right way. First, a quick summary.
Let's consider dev-libs/elfutils that has a dependency
on app-arch/bzip2. If we're building 32-bit elfutils, it needs 32-bit
libbz2. This is enforced through a dep in form of:
app-arch/bzip2[${MULTILIB_USEDEP}]
that gets expanded into:
app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,...,abi_mips_o32(-)?,...]
which means that any of the ABI_* flags that gets enabled on elfutils,
needs to be enabled on bzip2 as well. Of course, some of use.forcing
and masking gets applied here but that doesn't really matter.
Now, since we're pretty much converting a lot of different packages,
some of them are eligible for stabilization earlier than the others.
However, the extra MULTILIB_USEDEPs enforce stabilizing multilib
dependencies before the actual packages which made a few developers
unhappy.
That's why we decided to stable-mask the flags on affected packages.
Since the flags are masked on stable, people can stabilize packages
independently of whether their converted deps are stable or not. We
will be worrying about that consistency once we decide to unmask
the flags.
The extra advantage of that is that we can avoid pushing stable users
into the mess involved with partial conversion of emul-linux. The idea
is pretty simple: we keep emul-linux for stable, and once everything is
ready, we stable-unmask the flags and let stable users grok multilib.
Now, to the problem. Currently we're just stable-masking abi_x86_32
on amd64. This serves the latter purpose well and seems to work for the
former. This is probably because the remaining flag is use.forced
(abi_x86_64 on amd64, and abi_x86_32 on x86) which seems to add it to
implicit IUSE somehow.
floppym has done some research w/ stable elfutils and no stable
converted bzip2. It seems that if abi_x86_32 is stable.use.masked
and abi_x86_64 is use.forced, repoman groks it. However, if we remove
abi_x86_64 from use.force, it properly reports flag mismatch error
(since no stable bzip2 has IUSE=abi_x86_64).
Now, I honestly have no idea if this implicit use.force behavior is
PMS-y or not, and how other PMs handle it. I can't find something like
this in the PMS but that doc is horribly hard to cross-reference, so I
might be missing something. I'd appreciate if someone could help me
with that.
That said, I have an alternate idea inspired by the ppc breakage. I'm
thinking of replacing the amd64 abi_x86_32 mask with a global stable
mask of all abi_*_* flags on the relevant packages.
I'm not sure exactly what you mean here --- where/how does this global
stable masking happen? Right now you have a bunch of maskings of
abi_x86_32 on various packages in arch/amd64/package.use.stable.mask but
not on any other arches where you just have the use.mask/use.force
combination. Are you going to migrate the amd64 file to other multilib
arches and mask non-native abis? Like on mips64el/multilib/n32 would
you be masking abi_mips_o32 and abi_mips_n64 for all those packages?
Differences:
1) old solution: native flag is forced, other flags are masked.
new solution: all flags are masked.
2) old solution: we need to replicate the masks properly for different
arches/profiles.
new solution: we can keep a single mask for all arches.
This sounds like a partial answer to my above question.
3) old solution: MULTILIB_USEDEP magically works (w/ portage at least).
new solution: since all flags are disabled, MULTILIB_USEDEP
is a no-op and old packages match correctly.
4) old solution: forced native flag runs the native build.
new solution: fallback code runs the native build (since no flags
are enabled).
Your thoughts?
How does this "go live" once these flags are enabled? Do you just
remove the global mask all at once? That sounds a bit scarier than just
removing the masks one package + deps at a time. (Maybe a non-question
because I'm still now sure how this masking works.)
Also, I don't see that it should be an issue, but do you think this
might affect catalyst runs --- I have to ask because
repairing/reconfiguring seeds is a lot of work.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
