On Fri, 15 Nov 2013 12:25:47 -0800 Matt Turner wrote: > On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman > wrote: > Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for > kbproto but was attempting to emerge unstable (or unmasked abi_x86_32) > libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked), > unmerge kbproto and attempt to emerge libXt: > > [...] > > emerge: there are no ebuilds built with USE flags to satisfy > "x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]". > !!! One of the following packages is required to complete your > request: > - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) > (dependency required by "x11-libs/libXt-1.1.4" [ebuild]) > (dependency required by "libXt" [argument]) > > It suggests that I turn off abi_x86_32 for libXt rather than telling > me to turn the flag on for kbproto! Why should it literally suggest you to do something known to be broken? It is clear from the output how it wants the dependency to be; so, if you want to do something different, you can and the output tells enough. Due to the complexity of the dependency, you will need `man 5 ebuild` though; (-) means to assume it as disabled if it doesn't exist. > Portage prints other things intelligently: > > mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > > > [nomerge ] dev-python/py-1.4.13 USE="{test}" > PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6 > (-python3_3)" > [ebuild N ] dev-python/pytest-2.3.5 USE="{test} -doc" > PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6 > (-python3_3)" 417 kB > [ebuild N ] dev-python/py-1.4.13 USE="{test}" > PYTHON_TARGETS="python2_7 python3_2 (-pypy2_0) -python2_6 > (-python3_3)" 185 kB > > Total: 2 packages (2 new), Size of downloads: 602 kB > > * Error: circular dependencies: > > (dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on > (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge) > (buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for > merge) (buildtime) > > It might be possible to break this cycle > by applying the following change: > - dev-python/py-1.4.13 (Change USE: -test) > > Note that this change can be reverted, once the package has been > installed. This is just like how you can't compile gcc without having compiled gcc with another compiler first (or used a binpkg, or obtained from stage3); thus, similarly, you can't test py without having pytest first etc... For example, emerging dev-java/icedtea without a Java compiler / runtime present will show you the same behavior; and there are some other circular dependencies present in the tree that behave similarly. It's a problem that you can't really solve as far as I know; bugs are often getting filed for it, but without a fix. One filed against Portage is for example https://bugs.gentoo.org/show_bug.cgi?id=417675 but it hasn't received much attention; because well, I doubt if a proper solution to this would be simple. Workarounds mentioned are hacking up the vdb or changing --newuse. Does replacing this "explicit behavior" by "implicit behavior" make sense for the users in general? Does it make sense for those that just want to test? Will people understand it if it were implicit behavior? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D