On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <tom...@gentoo.org> wrote:
> On Fri, 15 Nov 2013 12:25:47 -0800
> Matt Turner <matts...@gentoo.org> wrote:
>
>> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <tom...@gentoo.org>
>> 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?
I don't know what you mean. kbproto[abi_x86_32] isn't known to be
broken. You're asking a really weird question based on some implicit
context that's not available to me.
I'm claiming in this example that attempting to emerge
libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
set for kbproto, rather than telling you to unset abi_x86_32 for libXt
(which you're requesting to be emerged, damn it!).
> 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...
I don't think you understood my intention for giving this example.
Portage correctly figures out the proper solution and suggests it. I'm
saying that this is a good thing.
