From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C9BCC1384B4 for ; Thu, 12 Nov 2015 09:05:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF34721C17F; Thu, 12 Nov 2015 09:05:14 +0000 (UTC) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7B0C121C115 for ; Thu, 12 Nov 2015 09:05:13 +0000 (UTC) Received: by wmec201 with SMTP id c201so81440800wme.1 for ; Thu, 12 Nov 2015 01:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=PsLMYZXM/gPhiRFl8qUpGRduagzXLwVI8dCEgtu0Jc8=; b=AfNT0+Xe9emhFhomZvpEvcZjxG0mU5XPf3D0qgUjwJaKL9CMOiD8SaNCbUA77La0lX 5kit5kPsxpXtArM57UDsQyUfnYgPdSTolOC6l9py0wbhaDccykLkILMt5PL8HsPJwk1e GaS3PzWsLVgVHEEigy0afWfWZek1Dl9ZdHwAQ+dhGcbJplg0CDIY4dWhyh6fdGIlz3tc x9v/n8Mwo8Onuz17JBah1iHrEW+wLwM4UqKh2yGGKOSU68sR41tJ35YRk09ac5oEXz9B 6gP1hLB2V+3QuBF+Ye8DHajFoQ3PE2+puKskkLw7qh0R+SwkbRI02YPAnFWCf2aROVFh l8vA== X-Received: by 10.28.10.132 with SMTP id 126mr41633969wmk.97.1447319112039; Thu, 12 Nov 2015 01:05:12 -0800 (PST) Received: from [172.20.0.40] ([165.255.82.143]) by smtp.googlemail.com with ESMTPSA id e189sm13897278wma.4.2015.11.12.01.05.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 01:05:11 -0800 (PST) Subject: Re: [gentoo-user] Re: Re: Emerge order not deterministic !? To: gentoo-user@lists.gentoo.org References: <20151111193548.GB12926@waltdnes.org> <5644486F.1090205@gmail.com> <56444E0A.5030309@gmail.com> From: Alan McKinnon Message-ID: <5644560A.4030403@gmail.com> Date: Thu, 12 Nov 2015 11:04:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 9291a2cd-0e09-4fe0-b41b-8056c846ba50 X-Archives-Hash: 38c04734b0af45f6b7c70554cb8761e1 On 12/11/2015 10:48, Jörg Schaible wrote: > Alan McKinnon wrote: > >> On 12/11/2015 10:29, Jörg Schaible wrote: >>> Alan McKinnon wrote: >>> >>>> On 11/11/2015 21:35, Walter Dnes wrote: >>>>> Ongoing installation. I looked at 2 instances of >>>>> "emerge -pv x11-base/xorg-server" and the order was somewhat different. >>>>> Here are a couple of outputs, just a few seconds apart. Is this a bug >>>>> or a feature? See attachments. >>>>> >>>> >>>> >>>> Emerge order is not deterministic, especially with parallel builds. The >>>> reason is that it does not need to be according to the dep graph - if >>>> two packages are at the same level and do not depend on each other, then >>>> the order they are built in does not affect the final result. >>>> Practically all parallel processing works this way. >>>> >>>> What is deterministic, is that if you build the same set of packages >>>> twice and even if portage does them in different order, the binaries >>>> produced are functionally identical >>> >>> Hmmm. And how can you then ever use >>> >>> emerge --resume --skip-fist >>> >>> if not even the first build is deterministic? I skip the first package >>> anyway only if the problematic package is the first one to build after >>> resume, but if I cannot even rely on that? >> >> >> Because it re-uses the previous build order, not re-generate a new one. > > That's simply not true. Emerge resume calculates the order again and for me > it starts often with a different package. I've never noticed that. For me --skip-first has always skipped the correct first package (the one that previously failed). As long as a known build failure is not in the --resume list, I don't care what the build order is because it is irrelevant. The only time it becomes relevant is when an ebuild has a bug such as a missing dep. But that's a bug in the ebuild and is fixed there. -- Alan McKinnon alan.mckinnon@gmail.com