[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Stable masks on multilib packages
From:       "Anthony G. Basile" <blueness () gentoo ! org>
Date:       2014-03-31 23:09:44
Message-ID: 5339F5B8.8000305 () gentoo ! org
[Download RAW message or body]

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    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


[prev in list] [next in list] [prev in thread] [next in thread]