Since freetype-2.5.3-r1 is a multilibbed ebuild that configures with $(use_with harfbuzz) on all arches, it needs to depend on harfbuzz[truetype,${MULTILIB_USEDEP}], not just harfbuzz[truetype]. This requires removing most of this package.mask: # Michał Górny <mgorny@gentoo.org> (28 Feb 2014) # New multilib conversions for testing, grouped with corresponding # emul-linux bumps. Please unmask in order, after getting ACK from # package maintainer. # # Notes: # - yngwin explicitly requested 30 days + 1 version bump for cairo. # - always unmask in order, with emul-linux of choice and *all* packages # preceding it >=dev-libs/libgcrypt-1.6.1-r1 dev-libs/libgcrypt:11 >=dev-libs/lzo-2.06-r1 >=app-emulation/emul-linux-x86-baselibs-20131008-r20 >=dev-libs/libxslt-1.1.28-r2 >=app-emulation/emul-linux-x86-baselibs-20131008-r21 >=x11-libs/cairo-1.12.16-r1 >=app-emulation/emul-linux-x86-gtklibs-20131008-r2 >=x11-libs/gdk-pixbuf-2.30.6-r1 >=app-emulation/emul-linux-x86-gtklibs-20131008-r3 >=media-gfx/graphite2-1.2.4-r1 >=media-libs/harfbuzz-0.9.26-r1 >=media-libs/libass-0.11 >=x11-libs/pango-1.36.2-r1 >=x11-libs/pangox-compat-0.0.2-r1 >=app-emulation/emul-linux-x86-gtklibs-20131008-r4 And for this we need an ack from yngwin (why do you need 30 days to review some simple multilib changes?) and openoffice team (for graphite2).
As I told you multiple times. Do whatever heck you think is correct as I have no better knowledge of the multilib stuff. Just expect yourself to be CCed on multilib bugs if raise.
As I've already indicated in bug #504544 multilib-enabled harfbuzz ebuild is still p.masked so we cannot simply add multilib dependency on this package in freetype unless we either - mask all multilib freetype ebuilds as well - unmask harfbuzz and all other depending ebuilds
(In reply to Lars Wendler (Polynomial-C) from comment #2) Unmasking multilib harfbuzz is obviously the right solution. Hence this bug report :)
By the way, as a data point, I've had one of my ~amd64 systems with ABI_X86="32 64" and everything in this mask unmasked since the beginning of March, and haven't seen any problems with the multilibbing.
*** This bug has been marked as a duplicate of bug 504544 ***
As long as this ebuild is masked, this is not resolved at all. We need 2.5.3-r1 to go stable at once, because of security bug #504088. Multilib should not interfere with that. If the harfbuzz multilib ebuild isn't ready for that yet, then you need to solve this another way.
(In reply to Ben de Groot from comment #6) The multilib ebuild for harfbuzz is ready; and multilib ebuilds for libgcrypt, libxslt, gdk-pixbuf, graphite2, libass, pango, and pangox-compat are also ready. As far as I can see, the only two parts of the mask that haven't been acked yet are lzo and cairo.
(In reply to Alexandre Rostovtsev from comment #7) > As far as I can see, the only two parts of the mask that haven't been acked > yet are lzo and cairo. Cairo multilib certainly isn't ready to go stable. So once again, this needs to be solved another way. Personally, I'd be happy with package.use.mask'ing the harfbuzz useflag for this.
(In reply to Ben de Groot from comment #8) > Cairo multilib certainly isn't ready to go stable. As far as I can tell, stabilizing cairo multilib is not needed; it only needs to be unmasked in ~arch. That will allow emul-linux-x86-gtklibs-20131008-r4 to be unmasked, which will allow harfbuzz-0.9.26-r1 to be unmasked without causing dependency problems in ~arch, and harfbuzz-0.9.26-r1 and fontconfig-2.5.3-r1 can then be stabilized together without cairo.
(In reply to Alexandre Rostovtsev from comment #9) To expand on this: harfbuzz uses cairo only for executables, so it doesn't need cairo multilib directly. The tie between harfbuzz multilib and cairo multilib arises via emul-linux-x86-gtklibs. And for now, it arises only in ~arch, because abi_x86_32 is package.use.stable.masked for emul-linux-x86-gtklibs on amd64.
(In reply to Ben de Groot from comment #8) > I'd be happy with package.use.mask'ing the harfbuzz useflag for this. Which is what I ended up doing.