There's a somewhat infamous dependency cycle between harfbuzz and freetype. Harfbuzz has a dependency: truetype? ( media-libs/freetype ) freetype has a similar dependency: harfbuzz? ( media-libs/harfbuzz[truetype] ) This is obviously unsolvable when building from source, without doing a complicated dance to build a stripped down version of one, so you can build the other, so you can rebuild the first. (Portage cannot handle this automatically, unfortunately.) Given we now have a public binhost, I was pondering how to solve this at least when installing from a binhost. I tried modifying freetype like this: https://paste.xinu.at/l5CosOlx/ Basically, move the dependency so that instead of being both in RDEPEND and DEPEND, have it in DEPEND and PDEPEND. The theory here is that: - you must satisfy harfbuzz[truetype] when installing binhost packages, but you can do it at any time, so PDEPEND is appropriate to resolve the binary-only cycle (it is not needed in pkg_* phases or anything). - you also must satisfy harfbuzz[truetype] when compiling freetype from source, and this is unsolvable without the complicated dance. So putting it in DEPEND is also appropriate. Attempting to test out this solution, I built a freetype binary package with harfbuzz support, then unmerged both packages to test out the process of bootstrapping this from a clean slate. Portage offered me what it considered a valid solution: 1) install freetype[harfbuzz] from a binary package 2) build harfbuzz[truetype] from source Step two failed because the DEPEND="freetype" is non-functional. It links to media-libs/harfbuzz which is not available at that time due to an unfulfilled PDEPEND. I was expecting to receive the current status quo, which is an error from emerge stating that there is a dependency cycle which I should try to solve by modifying my USE flags -- because when building from source, the dependency cycle is still there.
It has been pointed out to me that there's a loophole in PMS: - Runtime dependencies (RDEPEND). These must be installed and usable before the results of an ebuild merging are treated as usable. - Post dependencies (PDEPEND). These must be installed at some point before the package manager finishes the batch of installs. The sole purpose of post dependencies is to resolve cyclic dependencies as a last resort, which is what I tried to use it for. It is logically inconsistent for it to NOT be taken into account for satisfiability. Or perhaps I should say, it is logically inconsistent for PDEPEND to exist, but not have "PDEPEND except taken into account for the dependency graph". The existence of a PDEPEND="package-b" implies package-b is necessary for using package-a, so... how can I use package-a in another package before the batch of installs is done?
Maybe an alternative way to do what I was *trying* to do, is for EAPI 9 to permit merging RDEPEND in any order, ignoring cyclic dependencies, as long as there are NO pkg_* phases in any of the associated packages within that group. See bug 937150.
(In reply to Eli Schwartz from comment #2) > Maybe an alternative way to do what I was *trying* to do, is for EAPI 9 to > permit merging RDEPEND in any order, ignoring cyclic dependencies, as long > as there are NO pkg_* phases in any of the associated packages within that > group. This is what Portage currently does, and it's a mess. RDEPEND+PDEPEND let's us specify "install A first because it MUST be there, B is secondary". Back in the day setuptools would have a cyclic dep on certifi. certifi would be PDEP because you could use setuptools without it, so you could install everything else first to build certifi. Without that clarification, you could actually get non-functional setuptools.
