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 2FFB813865E for ; Thu, 24 Jan 2013 18:58:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E62F21C06B; Thu, 24 Jan 2013 18:58:10 +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 3DD8E21C03C for ; Thu, 24 Jan 2013 18:58:09 +0000 (UTC) Received: from [192.168.1.138] (CPE002401f30b73-CM001cea3ddad8.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 27E3B33DA95 for ; Thu, 24 Jan 2013 18:58:08 +0000 (UTC) Message-ID: <5101844B.8070005@gentoo.org> Date: Thu, 24 Jan 2013 13:58:19 -0500 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121208 Thunderbird/10.0.11 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default References: <50FE73F1.6090102@gmail.com> <51017B0A.4060608@gentoo.org> <510183B2.8020603@orlitzky.com> In-Reply-To: <510183B2.8020603@orlitzky.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 10d4e17c-c398-4ec5-b592-b0e2719caeb6 X-Archives-Hash: b69b516e37ef5e2c4644a46df4f72fc5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/01/13 01:55 PM, Michael Orlitzky wrote: > On 01/24/13 13:25, Rich Freeman wrote: >> On Thu, Jan 24, 2013 at 1:18 PM, Ian Stakenvicius >> wrote: >>> a fatal die in pkg_pretend could be circumvented by an >>> environment variable such as ${PN}_I_KNOW_WHAT_IM_DOING being >>> set. Just a thought. >> >> If we're going to do this I'd definitely have the ${PN} bit as >> you suggested. Otherwise everybody will just set it in make.conf >> and the feature will be pointless. Then we'll yell at users >> because they disabled the feature that normally just tends to >> break half their builds but this time by some miracle would have >> actually prevented a problem. > > Are there really that many ways that this could cause false > positives? (Not that I'm against the $PN prefix, just curious). > > I've only seen two legitimate examples: catalyst (whose developers > are more than capable of setting a variable) and a > supervisor-provided kernel for which you have no information. > How about, you know what you're doing and are going to build a new kernel as soon as the emerge finishes (since the emerge is also bringing in a new gentoo-sources)?? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEBhEsACgkQ2ugaI38ACPDYHAD/RCYlN6hcItJYn/gCcEdEgh+C owE/NaeGNDiH+3H/+uAA/jRfeJ+HPxDLdGNxt/VARcrqYnA15o6SmAiHOIj4i8Au =FTEj -----END PGP SIGNATURE-----