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 83D381381F3 for ; Tue, 30 Apr 2013 05:30:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5C823E08BD; Tue, 30 Apr 2013 05:30:35 +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 5879EE08B5 for ; Tue, 30 Apr 2013 05:30:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2AE5D33DA22 for ; Tue, 30 Apr 2013 05:30:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5.5 tests=[AWL=-0.073, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.442, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXZiJ3Vnj3ND for ; Tue, 30 Apr 2013 05:30:27 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D7A7C33DF6D for ; Tue, 30 Apr 2013 05:30:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UX38s-0008PX-1s for gentoo-dev@gentoo.org; Tue, 30 Apr 2013 07:30:18 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Apr 2013 07:30:18 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Apr 2013 07:30:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation? Date: Tue, 30 Apr 2013 05:30:03 +0000 (UTC) Message-ID: References: <20130429075549.06e8ad66@gentoo.org> <201304291436.42577.vapier@gentoo.org> <20130429194917.46d4985c@googlemail.com> <20862.56778.599974.921136@a1i15.kph.uni-mainz.de> <20130429215950.019cd23b@googlemail.com> <20862.62111.902255.208565@a1i15.kph.uni-mainz.de> <20130429232709.6d755604@googlemail.com> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT f3d4165 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 85707a08-99ef-4498-9612-6ea348518398 X-Archives-Hash: 15c1b4cdecc84d5be0259743bbbc4024 Rich Freeman posted on Mon, 29 Apr 2013 19:12:37 -0400 as excerpted: > This whole thing seems best chalked up to well-intending people making > omissions (maybe), and the virtue of competent developers who don't just > blindly follow the spec when it doesn't make sense. Actually, much as it's widely agreed there's value in porting an app to at least one other arch even if there's not enough potential users there to justify it directly, because it helps to root out and get bugs fixed that would never be found otherwise, I'd say the same applies here: There's value in someone being just contrarian enough to purposefully look for the strangest or most illogical read of a spec and (initially) implement it that way, in ordered to root out and get the bugs in the spec fixed. That said... > Sure, fix the spec, but it makes more sense to make this retroactive > unless somebody can really point to something that this breaks. Agreed. Once the bug has been demonstrated and a fix to the spec is in process, the value of a contrarian read of the existing spec has been exploited and there's no longer any value in it. Just fix it (both the spec and the contrarian implementations), as soon as possible (and possibly retroactively for the spec), which given the nature of specifications and the bureaucracy which surrounds them, will by definition tend to be sooner for the implementation than for the spec, a fix for which will take its time to work thru the bureaucracy. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman