Dnia 2014-04-01, o godz. 11:12:11 Ian Stakenvicius <[email protected]> napisał(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 31/03/14 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.
> >
> > 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.
> >
> > 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 messy is this going to be on current systems, if implemented?
> This -is- going to cause use flag changes on a whackload of packages,
> which at minimum I expect means a bunch of needless rebuilds.
>
> I think it's probably best to keep with the current path, and just
> hurry up the migration on x86. If we switch to masking all abi_*_*'s,
> then not only do we rebuild a whackload of packages now, but we also
> end up rebuilding them again when we remove the abi_*_* mask, -even
> if- the alternative abi's aren't needed.
Note that the same issue is spilling into ppc now that vapier wants to
introduce multilib there. If we keep going the current way, we need to
mask abi_ppc_32 in the ppc profiles, and that means yet another copy of
the same mask to maintain in sync.
> A note on #3: if MULTILIB_USEDEP -isnt- working on other PMs, i hope
> we have bug reports and we should work to resolve those ASAP or
> abandon the project/find a different solution. We're over a year into
> it though (i think?) so i expect it's fine since I don't remember
> hearing of any issues yet...
I don't know how many people are using Gentoo with alternative PMs
and stable keywords. I think Paludis could be a case but then, I don't
know how Exherbo incorporates our multilib into their package system.
> on a side note, to follow up -- when we do remove the masks, what're
> the thoughts on perhaps changing the multilib profile on amd64 to
> auto-enable abi_x86_32 flags on some packages? Indeed, if the
> toolchain is converted to multilib-build, would this be enough to
> differentiate between amd64-multilib and pure64? (bootstrapping may
> of course still be a problem if users are trying to switch, but
> probably not any more of a problem than it is right now, right?)
Could you be more specific on which packages? I used to think about
enabling it globally but now I see that autounmask would do a pretty
good work of unmasking the flags whenever necessary.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
