Date: Mon, 25 Jan 2016 16:24:07 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> 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> In-Reply-To: <56A619BC.7080802@marino.st> References: <201601221319.u0MDJbbm075196@repo.freebsd.org> <20160125085654.GB95732@FreeBSD.org> <56A5EFD5.8080804@marino.st> <20160125123904.GA96711@FreeBSD.org> <56A619BC.7080802@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160125162407.GA81295>