From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66515-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 2CFCB13877A
for <garchives@archives.gentoo.org>; Mon, 7 Jul 2014 23:42:15 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5B096E0869;
Mon, 7 Jul 2014 23:42:10 +0000 (UTC)
Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 699ECE085C
for <gentoo-dev@lists.gentoo.org>; Mon, 7 Jul 2014 23:42:09 +0000 (UTC)
Received: by mail-ve0-f180.google.com with SMTP id jw12so4810806veb.39
for <gentoo-dev@lists.gentoo.org>; Mon, 07 Jul 2014 16:42:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=jF9vCbKdaQ1Qe1/q4/hrWjiSEg+snZmV6LQvtzqTRU8=;
b=dk5kfYX1ngK/sHrV5+Ll3R5RRbcblrARVWtP9viBzp2AGB2yi28C/yIj/tAQUSVek0
CEEPwWEsu6Fw1o6mY6zk6ln5nMB3QTd7a/a8RrQ9/cqkv0TQyhvCxJJ0ifiq3AFQ2RhW
1TP3fXRNKwlazA8fPwzeE5a2acRI1M3fZ7XowEVhcwDVdwm6Vzx3AWLuCnusJM6Rp4aJ
1qawtK5QfKKp+ncQqJWWTMVZpDuR1HnsKGX21cMK5ZBQKW18KHuQQD/GQNnhBzem5FMp
jzcsVOnwNLKp8TbMf2NUzNjeBTj8quuGVOb0ZyzmHH5c2slF0pq3+A1J5+027/XRtEFD
hUZQ==
X-Gm-Message-State: ALoCoQmJErjMccl8il4LKZqmcTgQqXBw6uYG2Dmso95MReAmrl7sUjUZjmtURCVuMd6ONNJloHd1
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.220.69.68 with SMTP id y4mr30414308vci.21.1404776528326;
Mon, 07 Jul 2014 16:42:08 -0700 (PDT)
Sender: gmt@be-evil.net
Received: by 10.220.141.207 with HTTP; Mon, 7 Jul 2014 16:42:08 -0700 (PDT)
X-Originating-IP: [75.147.143.254]
In-Reply-To: <CAGfcS_mdTAdU+NxRKG3Cg_dtYr4Oq6dK8QRUiWFSnVZk-snqKA@mail.gmail.com>
References: <CA+VB3NQEgYMtkjYjRBdS1nsKf1MjzONF9LN2LmXJ45qSx2so6A@mail.gmail.com>
<CAGfcS_mdTAdU+NxRKG3Cg_dtYr4Oq6dK8QRUiWFSnVZk-snqKA@mail.gmail.com>
Date: Mon, 7 Jul 2014 16:42:08 -0700
X-Google-Sender-Auth: pCtuMveyhGpvnAbXDXdm3SFZu8A
Message-ID: <CA+VB3NSz9pDwF5z_gAhZPM-4m5=Yv23AL+hAxam_zmb0RnC7FQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Is || ( Atom... ) broken?
From: Greg Turner <gmt@malth.us>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 0e31f6ec-ada7-4e46-8062-8218d5897fcd
X-Archives-Hash: e69392eacc8bc68fb2ba366820fa6a31
On Mon, Jul 7, 2014 at 4:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
> Well, more like unspecified behavior. PMS just says that the PM has
> to accept any package in the list. It is silent on the matter of
> which one is to be preferred, or to what degree.
In general the PMS dependency language seems quite liberal here. As
best I can tell, the PMS only stipulates something to the effect of:
"the PM has to meet the conditions matching the dependency specifiers
in the ebuild before running the phase functions" but doesn't provide
any guidance as to /how/ the PM should make it so, if it isn't at the
outset. Assuming I haven't missed something that contradicts or
narrows that reading, I have mixed feelings about it. While it feels
inscrutable, it gives us a lot of freedom to fix the problem.
> As we saw with upower portage will jump through quite a few hoops to
> install the first dependency - it doesn't always figure out that
> installing one of the others is easier. It is a bit hard to
> algorithmically define "easier" - should portage favor fewer package
> installs, fewer removals, fewer config file changes, avoiding changing
> the init system (and what constitutes an init system), etc? Plus,
> there are a lot of potential permutations to deal with.
Yes, agreed. The. However, the case where the PM has more than one
possible way to get there, although tricky/interesting, is not what
inspired me to post this.
I was hacking on my private overlay's pipelight-plugin ebuild, which
had deps like:
DEPEND="|| (
>=app-emulation/wine-1.7.21[pipelight]
>=app-emulation/wine-compholio-1.7.14
)"
when I tried to emerge, it insisted on wine[pipelight] even though I
already had wine-compholio installed.
Now that I think about it, the probable explanation was pretty
obvious: portage saw I had wine installed, and therefore said "that's
the one," and headed obstinately down that path, finally deciding,
"OK, but you need to enable the pipelight use-flag and rebuild wine".
I wonder what would have happened if I'd had --autounmask=n in the
command-line.
> I think most would agree that there is room for improvement here.
Some in this thread have argued that since there's an easy workaround
this is not a particularly important issue. Fair enough, but while,
for most of the people reading this thread, that may be so, I have a
couple of friends who are casual users of portage, and they finds
these situations to be more-or-less utterly intractable. I don't mind
them asking me for help, but what does suck is I usually wind up
having to tell them to use -O, a feature I'd rather they didn't need.
It seems pretty clear to me that, recently, people who "didn't do
anything crazy" are experiencing depsolving failures more and more
(perhaps due to the explosion of multilib-build ebuilds in the tree --
no pun intended :)).
I can only imagine how difficult the experience of someone trying
Gentoo for the first time must be today: Casual experimenters
presumably give up after encountering a failure or three justified by
more screenfulls of colorful gibberish than their consoles can hold in
scroll-back before even getting grub installed. One can see how they
might conclude Gentoo is either broken, or only for for people more
technically inclined than they.
Indeed, truth be told, a reasonable person could defend either proposition.
One other note. If we think "X would make portage dep-solving even
slower, so, screw that, we have bigger fish to fry," that means slow
dep-solving has effectively become a blocker for enhancement/bugfix X.
Not saying it shouldn't be, just that it's food for thought*.
As for the idea of reverting portage -- with some effort, we could
revert the dep-solving changes while leaving any important bugfixes
intact (effectively, I guess, backporting the latest portage to the
old portage.dep).
But, I suspect, the result would be, we'd find things were not so rosy
a year ago or whenever. Gentoo-x86 had a /lot/ less hairy EAPI4+
use-conditional dependency cascades a year ago, so of course things
were faster. If someone were to prove me wrong with some benchmarks,
though, I'd happily admit I was mistaken.
TBH I keep flirting with the Gordian-knot theory that only a complete
gut-rehab of portage.dep can rescue us...
--
gmt
*Indeed, I'd estimate I often have to wait a half-hour on my 32GB
workstation to get a plan from emerge -DuavN @world, so for me that's
a bigger problem than anything else about portage right now.