Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@www.apache.org Received: (qmail 84001 invoked from network); 9 Nov 2005 02:52:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Nov 2005 02:52:04 -0000 Received: (qmail 8249 invoked by uid 500); 9 Nov 2005 02:52:03 -0000 Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 8126 invoked by uid 500); 9 Nov 2005 02:52:03 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 8114 invoked by uid 99); 9 Nov 2005 02:52:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2005 18:52:03 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [128.183.17.62] (HELO gamma.gsfc.nasa.gov) (128.183.17.62) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2005 18:51:56 -0800 Received: from alderaan.gsfc.nasa.gov (alderaan.gsfc.nasa.gov [128.183.16.213]) by gamma.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id jA92pf1M006556; Tue, 8 Nov 2005 21:51:41 -0500 Received: from alderaan.gsfc.nasa.gov (localhost.localdomain [127.0.0.1]) by alderaan.gsfc.nasa.gov (8.12.10/8.12.9) with ESMTP id jA92pfRe002329; Tue, 8 Nov 2005 21:51:41 -0500 Received: (from sabol@localhost) by alderaan.gsfc.nasa.gov (8.12.10/8.12.10/Submit) id jA92pfYs002325; Tue, 8 Nov 2005 21:51:41 -0500 Date: Tue, 8 Nov 2005 21:51:41 -0500 Message-Id: <200511090251.jA92pfYs002325@alderaan.gsfc.nasa.gov> From: "Edward J. Sabol" To: apreq-dev@httpd.apache.org In-reply-to: <87r79qsgm6.fsf@gemini.sunstarsys.com> (message from Joe Schaefer on Tue, 08 Nov 2005 21:24:33 -0500) Subject: Re: towards a 2.07 release References: <87r7b3cnlz.fsf@gemini.sunstarsys.com> <43432562.7020107@stason.org> <87wtkq8qun.fsf@gemini.sunstarsys.com> <4345795A.3060303@stason.org> <87r79qsgm6.fsf@gemini.sunstarsys.com> X-Scanned-By: MIMEDefang 2.49 on 128.183.16.146 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > So I don't know how to proceed at this point. We could either > > 1) leave things as-is, which allows the cpan client to sift through the > generated Makefile in order to pursue unsatisfied prereqs, > > or > > 2) change back the "warn" calls to "die", which will confuse the cpan > client, but will allow human users to figure out exactly what needs to > be done in order for the build to continue. > > Opinions? It seems to me that both are desirable under different circumstances. Does it make sense to add an option to configure.pl ("--die-if-prereqs-fail"?) which controls this?