From: Peter Humphrey <peter@prh.myzen.co.uk>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Two identical systems - different!
Date: Sun, 02 Mar 2014 19:35:09 +0000 [thread overview]
Message-ID: <1531721.jL4oMuOvz0@wstn> (raw)
In-Reply-To: <20140302181404.49bc21b7@gentoo.org>
On Sunday 02 Mar 2014 18:14:04 yac wrote:
> On Sun, 02 Mar 2014 14:59:49 +0000
> Peter Humphrey <peter@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
next prev parent reply other threads:[~2014-03-02 19:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-01 22:34 [gentoo-user] Two identical systems - different! Peter Humphrey
2014-03-02 11:21 ` yac
2014-03-02 14:59 ` Peter Humphrey
2014-03-02 17:14 ` yac
2014-03-02 19:35 ` Peter Humphrey [this message]
2014-03-02 15:28 ` netfab
2014-03-02 20:21 ` Peter Humphrey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1531721.jL4oMuOvz0@wstn \
--to=peter@prh.myzen.co.uk \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox