svn commit: r406930 - head/archivers/file-roller

[Alexey Dokuchaev]

On Mon, Jan 25, 2016 at 10:50:13AM +0100, John Marino wrote:
> On 1/25/2016 9:56 AM, Alexey Dokuchaev wrote:
> > On Fri, Jan 22, 2016 at 01:19:37PM +0000, John Marino wrote:
> >> New Revision: 406930
> >> URL: https://svnweb.freebsd.org/changeset/ports/406930
> >>
> >> Log:
> >>   archivers/file_roller: Fix ambiguous RUN_DEPENDS
> >>   
> >>   file_roller requires the ports version of unzip (I'm assuming based on
> >>   makefile's specifications).  However, since the full path to unzip
> >>   was not specified, the base unzip satifies the requirement which results
> >>   in the archivers/unzip package not being registered as a run dependency.
> >>  
> >> [...]
> >>  RUN_DEPENDS=	gtar:${PORTSDIR}/archivers/gtar \
> >> -    		unzip:${PORTSDIR}/archivers/unzip
> >> +    		zipinfo:${PORTSDIR}/archivers/unzip
> >> +
> >> +# Port unzip is desired, but specify the uniquely named zipinfo to ensure
> >> +# archivers/unzip is pulled in.  Using "unzip" is satisfied by base unzip
> > 
> > Another option would be to specify full path of unzip(1), i.e.
> > ${LOCALBASE}/bin/unzip:...  This would also reflect the reality, since if
> > base unzip(1) is not sufficient beyond trivial usecases (which is probably
> > the reason why `archivers/file-roller' wants "real" unzip -- e.g. the one
> > that support encrypted archives and stuff).
> 
> zipinfo is a symbolic link to $LOCALBASE/bin/unzip, so I used it to
> minimize the change.

Hmm, but how is the fact that zipinfo is a symlink $LOCALBASE/bin/unzip is
irrelevant?  The port wants unzip (not zipinfo), and the granule of change
is a line; regardless of the contents, it's -1 +1.

> I saw the two as equal and thus "dealer's choice" and I chose the latter.

Having to add an explanatory comment makes it -1 +n, so the two get a little
less equal once you consider this. ;-)

./danfe