From owner-freebsd-ports@FreeBSD.ORG  Fri Jul 20 20:00:07 2007
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
Delivered-To: ports@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4581616A418
	for <ports@freebsd.org>; Fri, 20 Jul 2007 20:00:07 +0000 (UTC)
	(envelope-from linimon@lonesome.com)
Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66])
	by mx1.freebsd.org (Postfix) with ESMTP id 2A2E413C428
	for <ports@freebsd.org>; Fri, 20 Jul 2007 20:00:07 +0000 (UTC)
	(envelope-from linimon@lonesome.com)
Received: by mail.soaustin.net (Postfix, from userid 502)
	id BB0FDE4E; Fri, 20 Jul 2007 15:00:03 -0500 (CDT)
Date: Fri, 20 Jul 2007 15:00:03 -0500
To: Bill Moran <wmoran@collaborativefusion.com>
Message-ID: <20070720200003.GC8179@soaustin.net>
References: <20070720085855.99fb2109.wmoran@collaborativefusion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070720085855.99fb2109.wmoran@collaborativefusion.com>
User-Agent: Mutt/1.5.9i
From: linimon@lonesome.com (Mark Linimon)
Cc: ports@freebsd.org
Subject: Re: Overly restrictive checks in the make process
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports>
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
	<mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2007 20:00:07 -0000

On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote:
> Why?  Is there a legitimate reason why the fetch process refuses to
> download this?

The intention of the logic is to warn a user, as soon as possible, that
they are spending time on something that will wind up being IGNOREd if
it is installed.  There is no logic there to try to figure out "later
version of port"; it simply looks for "is IGNORE set?"

Since some downloads take a long time, this does not seem too unreasonable
to me.

If we moved the check later, the process of trying to install a port that
would be IGNOREd would be: spend time fetching and checksumming it, and
only then tell the user that they had wasted their time.

I think the best we could do is add something analagous to how
DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only
if demanded, but turn it off by default.

mcl