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 1O7xLE-0000C6-LM for garchives@archives.gentoo.org; Fri, 30 Apr 2010 21:01:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65F7EE0786; Fri, 30 Apr 2010 21:01:40 +0000 (UTC) Received: from s15216962.onlinehome-server.info (forum.psychotherapie.org [217.160.22.205]) by pigeon.gentoo.org (Postfix) with ESMTP id 44D63E0724 for ; Fri, 30 Apr 2010 21:01:10 +0000 (UTC) Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3) with UUCP id o3UL1AC9020382 for gentoo-dev@lists.gentoo.org; Fri, 30 Apr 2010 23:01:10 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id o3UGWU8O018630 for gentoo-dev@lists.gentoo.org; Fri, 30 Apr 2010 18:32:30 +0200 Date: Fri, 30 Apr 2010 18:32:30 +0200 From: Enrico Weigelt To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel Message-ID: <20100430163228.GB492@nibiru.local> References: <4BC52478.3020303@gentoo.org> <4BC564B7.2090103@gentoo.org> <4BCED4C6.7010304@gentoo.org> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCED4C6.7010304@gentoo.org> User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: fdc195d6-44a7-4fc1-827d-b16a6d0124b8 X-Archives-Hash: b63c0c83ab4c9b9df71886ebbdb6e86b * Luca Barbato schrieb: > I wonder if that case shouldn't be handled better with an huge ewarn so > people concerned would really run it in a benchmark environment, alone. ewarns should be circumvented (make it work w/o them), IMHO. I can imagine I'm not the only person who doenst want to keep an close eye on each single build/merge. In this concrete example, the package's build system is misdesigned. They shouldn't rely on runtime benchmarks for build time decisions in the first place - this is unpredictable. But this is not an issues distros should have to cope with. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------