From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63602-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 22AC9138247
for <garchives@archives.gentoo.org>; Fri, 15 Nov 2013 21:22:25 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 8B459E09EA;
Fri, 15 Nov 2013 21:22:18 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 87EA6E09A9
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 21:22:17 +0000 (UTC)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: mattst88)
by smtp.gentoo.org (Postfix) with ESMTPSA id 6D10A33F1D4
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 21:22:16 +0000 (UTC)
Received: by mail-lb0-f180.google.com with SMTP id u14so3173125lbd.11
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 13:22:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=5AGdjaEGASOHc+irGonjbtFC7tD99u1jWbrht2p4VIk=;
b=iAzstSaYavFJQo/xYLw0hKieQZ3Zxf14/xtUGIe9kRYXBS3mxtGrtySLt5Ol22uX5l
rw2KUfDPzIZ7oiKiAQYI5VcMaR+EDyq1zDNufXxkF44xEsIaBxXeGZiglOq11/oGlA3X
kSEd45tQpyKjZ7a7MVD/sHitnMrZiovKMLwNyKrvIhlzie4e1YSdfpVuozwDrOp5pO8v
bvr/hQAb2ncesWMcjKMlaMEtj1z8rRGqhcEQOp/Hx5YcIELRmEI8e6t39bwKxYlu9a46
S4xh4AZvJ0F/H88l8D+aLENxfekHdshbxilcDP8C/eA5OjOe9AxxlA8Hm6FYHxqmhPki
5FYQ==
X-Received: by 10.112.167.3 with SMTP id zk3mr4976591lbb.23.1384550533999;
Fri, 15 Nov 2013 13:22:13 -0800 (PST)
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
Received: by 10.112.61.130 with HTTP; Fri, 15 Nov 2013 13:21:53 -0800 (PST)
In-Reply-To: <20131115215333.4db15ea8@TOMWIJ-GENTOO>
References: <slrnl86l1s.j7e.vaeth@lounge.imp.fu-berlin.de> <CAEdQ38GuN0s8K9SLbevhTL6AM=1oWKdpjGVGiR2JOC1mQ1VdxQ@mail.gmail.com>
<20131115210033.4fee8516@TOMWIJ-GENTOO> <CAEdQ38GLpxFnw6VvfeiEMtWwZbRiUK-3tHT5dd7JuZVQD_QAFA@mail.gmail.com>
<20131115215333.4db15ea8@TOMWIJ-GENTOO>
From: Matt Turner <mattst88@gentoo.org>
Date: Fri, 15 Nov 2013 13:21:53 -0800
Message-ID: <CAEdQ38GZYC+6W5=eRfsx8YW4cMFzZ_2E4dbbrvn+JZXo2od=aw@mail.gmail.com>
Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
To: Tom Wijsman <TomWij@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 031b71f0-ec79-42c8-9f01-fb113dd3c9db
X-Archives-Hash: 95c0f6d2f969a614bb20964fb1dffb7f
On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 15 Nov 2013 12:25:47 -0800
> Matt Turner <mattst88@gentoo.org> wrote:
>
>> On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman <TomWij@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.