On Sunday 02 Mar 2014 18:14:04 yac wrote: > On Sun, 02 Mar 2014 14:59:49 +0000 > Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > On Sunday 02 Mar 2014 12:21:24 yac wrote:
--->8 > > > Please provide the whole output. There should be an explanation why > > > there is the conflict. --->8 > > I ran three commands: > > 1. emerge -epvK world > emerge.with-K > > 2. emerge -epvk world > emerge.with-k > > 3. emerge -epv world > emerge.no-Kk > > > > Those three files are attached. (I pasted the STDERR text into the > > first one because I couldn't remember the bashism for redirecting > > both output streams to a single file.) > > The slot conflict occurred in case 1. It did not occur in cases 2 and > > 3, but the package list was ordered differently. > > -K makes portage to use *only* pre-compiled binary packages, so I guess > there's the problem. Yes, and that's why I used it - portage is supposed to abort if no suitable package exists. I don't believe that's reliable either; I have some evidence that it sometimes carries on silently, ignoring the missing package. In any case, it shouldn't fail to find an actually present package, namely app- arch/bzip2-1.0.6-r3. And the only USE flags used by that package are "static" and "static-libs", neither of which is set. > As you say you are not getting conflicting on later commands, the issue > is fixed for you, right? No, I said the conflict occurs if I pass -K to portage, but not if I pass -k or don't pass either. It's repeatable. Sorry if that wasn't clear. --->8 > > > What is the reason you run with backtrack=100 ? > > Actually it seems you are not setting anything as portage doesn't read > the OPTIONS variable [1]_. > > .. [1] > http://git.overlays.gentoo.org/gitweb/?p=proj%2Fportage.git&a=search&h=HEAD > &st=grep&s=OPTIONS I don't follow. What is that page telling me? Besides, I don't believe that portage ignores OPTIONS passed to it, as it has accepted them many times before now. -- Regards Peter
