From owner-svn-ports-head@freebsd.org Wed Mar 9 08:00:56 2016 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E93D89DB0E6; Wed, 9 Mar 2016 08:00:56 +0000 (UTC) (envelope-from netbsd@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9F0F961; Wed, 9 Mar 2016 08:00:56 +0000 (UTC) (envelope-from netbsd@marino.st) Received: by shepard.synsport.net (Postfix, from userid 80) id C429D43C11; Wed, 9 Mar 2016 02:00:48 -0600 (CST) To: Bryan Drewery Subject: Re: svn commit: r410612 - head/devel/libc++ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Mar 2016 09:00:48 +0100 From: "John Marino (NetBSD)" Cc: John Marino , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org In-Reply-To: <56DFADDC.1050204@FreeBSD.org> References: <201603081248.u28Cmpw6061510@repo.freebsd.org> <56DFADDC.1050204@FreeBSD.org> Message-ID: <0b8d469c87c4688af433ad0a702e419e@secure.marino.st> X-Sender: netbsd@marino.st User-Agent: Roundcube Webmail/0.9.1 X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 08:00:57 -0000 On 2016-03-09 06:00, Bryan Drewery wrote: > This is a synth bug and should be reverted. Right now make -V LIB_DEPENDS shows accurately under every platform where it did not before. Who would wish to revert it? Or in other words, who thinks the previous version of libc++ is "more correct" than the current version? > LIB_DEPENDS is already conditional on the specified library being > missing. The tool should only add the dependency if the library is not > present because that is the behavior of LIB_DEPENDS (and *_DEPENDS) in > ports without tools, meaning it is the intended behavior. This was > broken in portupgrade until r387621 I was 90% sure LIB_DEPENDS was designed to do what it was doing, but frankly I think it's technically a terrible design decision. Now that you have two build tools that were negatively affected by it, that opinion has merit. In other words, if anything, I'd like to formally re-evaluate that decision that have LIB_DEPENDS not being trustworthy as being ok with the goal of getting concurrence that it must be trustworthy. e.g. LIB_DEPENDS most propagate to the built package and if it doesn't it's wrong. 1) There cannot be many ports left in the tree that were doing what libc++ was doing. e.g. < 5 ? 2) it's easy to set LIB_DEPENDS conditionally 3) the current way is a POLA violation (IMO) and causes problems with package validity checks. It is an unwanted side effect and it's easily fixed. It requires people to understand technicallhy what package is doing? Can we do the right thing here? John