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

[Alexey Dokuchaev]

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 "package<condition>pkgversion:..." 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