From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1O22Ap-0003zl-O6 for garchives@archives.gentoo.org; Wed, 14 Apr 2010 12:58:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 542ECE083A; Wed, 14 Apr 2010 12:58:16 +0000 (UTC) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by pigeon.gentoo.org (Postfix) with ESMTP id E0981E0825 for ; Wed, 14 Apr 2010 12:57:56 +0000 (UTC) Received: by bwz9 with SMTP id 9so92978bwz.29 for ; Wed, 14 Apr 2010 05:57:55 -0700 (PDT) Received: by 10.204.6.81 with SMTP id 17mr8513091bky.62.1271249874982; Wed, 14 Apr 2010 05:57:54 -0700 (PDT) Received: from pomiot.lan (213-238-106-44.adsl.inetia.pl [213.238.106.44]) by mx.google.com with ESMTPS id 13sm456089bwz.11.2010.04.14.05.57.53 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 05:57:54 -0700 (PDT) Sender: Spam Box Date: Wed, 14 Apr 2010 14:58:20 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel Message-ID: <20100414145820.443a3d91@pomiot.lan> In-Reply-To: <4BC564B7.2090103@gentoo.org> References: <4BC52478.3020303@gentoo.org> <4BC564B7.2090103@gentoo.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/P1hnLwhpjgH5DhIftyGS5_Z"; protocol="application/pgp-signature" X-Archives-Salt: d1d19e2e-7547-4378-8112-6ea7ead7448a X-Archives-Hash: 2b212a8dc47e60c7b48278250f67e43f --Sig_/P1hnLwhpjgH5DhIftyGS5_Z Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 14 Apr 2010 08:46:15 +0200 Justin wrote: > There is at least one other example which benefits from singlular > build, atlas libs. They run a benchmark suite to create platform > specific headers, which is heavily influenced by the system load. So > having RESTRICT=3Dparallel would make the emerge more reliable. And that's another example of working around broken ideas. There is an uncountable number of possibilities of many different factors affecting the system load, and thus the results of the benchmark. Removing one of them would indeed help in many cases but in many other it wouldn't make any difference, additionally slowing down the whole system update process. Please notice that in order to implement that correctly, emerge would have to wait until all previously running emerges are done, and avoid running further ones while the build process is running. While in the case of xorg-server, the 'lock' is needed throughout the whole build process, in your case it is needed only for a short amount of time when the benchmark is being performed --- and the 'real' part of building would unnecessarily block emerge. If this is ever to be implemented, it totally needs to be user-overridable. Else, we'll end up someday like Windows, forcing user to reboot the system and perform the merge on a dedicated runlevel. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/P1hnLwhpjgH5DhIftyGS5_Z Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkvFu/MACgkQnGSe5QXeB7selQCgyzo3EC2TRe8fkz8BVxdhts2w v/EAoKkStGHPp3WfZsm2wbFgkaGw/6F/ =wwMU -----END PGP SIGNATURE----- --Sig_/P1hnLwhpjgH5DhIftyGS5_Z--