Re: [gentoo-dev] Stable masks on multilib packages

[Michał Górny]

Dnia 2014-03-31, o godz. 19:09:44
"Anthony G. Basile" <blueness@g.o> napisał(a):

> On 03/31/2014 06:16 PM, Michał Górny wrote:
> > 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?

The new solution would be base/package.use.stable.mask that would mask
all of multilib on all stable arches, on this long list of packages.
So, not only the two ABIs but all of them. Which would effectively make
ebuild behave like it had no multilib at all.

> > 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.)

Something like this, yes. Once all packages are migrated and some time
passes, we unmask all the flags locally and do a repoman run. We find
out what needs to go stable, report bugs, wait and repeat.

Then we do a second stabilization request, this time for testing
the tree (mostly emul-linux replacement) with multilib enabled. Once
arch teams are done testing, they remove the stable masks for
particular ABI.

When all reverse dependencies are fixed to use || () deps instead of
emul-linux (and rev-bumped) we can move away from emul-linux through
the usual procedure of last rites with a proper announcement. This is
likely the most fragile step of all but we will do our best to make it
as simple as possible, and I think our users can handle that.

> 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.

Well, I think this mostly depends on whether you want multiple multilib
ABIs in stages -- or if you assume that the toolchain is enough,
and people will build other ABIs as they need.

Though I think that once toolchain switches to abi_* flags (vapier
seems to show interest in that), we will use.force the necessary ABIs
on it and its dependencies, so there should be no explicit need for
change.

However, I guess the toolchain changes will be sent out for testing
anyway, so releng can check first hand.

-- 
Best regards,
Michał Górny