From owner-svn-ports-head@freebsd.org Mon Jan 25 16:24:07 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 36002A45497; Mon, 25 Jan 2016 16:24:07 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2B980221; Mon, 25 Jan 2016 16:24:07 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 2A12E1E1B; Mon, 25 Jan 2016 16:24:07 +0000 (UTC) Date: Mon, 25 Jan 2016 16:24:07 +0000 From: Alexey Dokuchaev To: marino@freebsd.org Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r406930 - head/archivers/file-roller Message-ID: <20160125162407.GA81295@FreeBSD.org> References: <201601221319.u0MDJbbm075196@repo.freebsd.org> <20160125085654.GB95732@FreeBSD.org> <56A5EFD5.8080804@marino.st> <20160125123904.GA96711@FreeBSD.org> <56A619BC.7080802@marino.st> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A619BC.7080802@marino.st> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 25 Jan 2016 16:24:07 -0000 On Mon, Jan 25, 2016 at 01:49:00PM +0100, John Marino wrote: > On 1/25/2016 1:39 PM, Alexey Dokuchaev wrote: > > On Mon, Jan 25, 2016 at 10:50:13AM +0100, John Marino wrote: > > > > Hmm, but how is the fact that zipinfo is a symlink $LOCALBASE/bin/unzip > > is relevant? The port wants unzip (not zipinfo), and the granule of > > change is a line; regardless of the contents, it's -1 +1. > > In my view, what it _wants_ is to register the package. It doesn't > matter what causes the register, only that it's registered. I could > have just as easily requested a man page and it would still work as > intended. There are two philosophically different views on *_DEPENDS. Technically new-school scheme of "packagepkgversion:..." is more flexible, and, as some people rightfully argue, is more in line with "what it wants is to register the package" (optionally, specific version). However ... > Now, for those susceptible to pedantism, I can see how it would seem > less correct but the whole "_DEPENDS" scheme is like this. We don't > list *every* file a port might depend on, we just pick one. That one > file is enough to create the registry. .., I kind of like being able to depend on specific binary or a library as it gives an immediate idea exactly *what* consumers expect from the dependency. Technically, it might not be that important (e.g. not every FOO_DEPENDS parser even obliged to check if the left part of semicolon actually exists and would install the port on the right unconditionally; I think it is (was?) true for p*re, but not for tinderbox and "manual" installation from the ports tree). But it is still a nice hint for us porters, and that's why I prefer $localbase/bin/unzip vs. infozip here: you just clearly tell readers exactly what's needed rather than trying to enforce the buildbot logic (and as a careful committer, putting that comment there -- again, thanks for doing it -- most folks won't bother). It can also serve as a reminder to make sure that the package *actually* calls $localbase/bin/unzip rather than limited /usr/bin/unzip (think of encryption support again to see the point) upon further port updates. > Given that point of view, and given that zipinfo cannot exist without > unzip, I see those as equivalent. Right; my point is that while infozip is "correct enough", it lacks the non-essential and non-required metainformation on exactly what bits of `archivers/unzip' are needed for the port's proper (designed) operation. > TLDR; > Whatever guarantees the dependency registry is correct enough because > the actual file is can never be considered representative of the true > requirement. That is a fair point (one of the arguments of new-age scheme supporters). Then again, if user puts their own, unregistered $localbase/bin/{info,un} zip they're asking for trouble IMHO, and we can't eat our hearts to give them 100% support. > Maybe, but I wanted somebody to pause before changing it in the future. Understood; by saying all the above I'm not implying any immediate action (but certainly welcome any fruitful discussion on the matter). ./danfe