Date: Sat, 18 Feb 2017 16:56:46 -0500 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Jan Beich <jbeich@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Misuse of PORTREVISION (Re: svn commit: r434379 - head/multimedia/x265) Message-ID: <f23cecfc-d669-e62b-1916-1e16e66fb3eb@aldan.algebra.com> In-Reply-To: <20170218210541.82AA915F6@freefall.freebsd.org> References: <20170218210541.82AA915F6@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18.02.2017 16:05, Jan Beich wrote:
> Can you bump PORTREVISION in consumers?
Just did. But I believe, our usage of PORTREVISION is wrong-headed.
> multimedia/ffmpeg recently enabled X265 by default but tools relying on "pkg version" may not
> notice the change which would leave users with an error e.g.,
Such tools are broken -- and our practice of relying on PORTREVISION for
such things is wrong. Changes to the value should mean: "this port was
modified in some way, even though the upstream's version remained the same".
Unfortunately, in addition to the above, changes to the PORTREVISION can
also indicate: "something this port depends on has changed".
This additional meaning should not be there:
* If it can be deduced, it should not need to be explicitly said.
* It is misleading -- we aren't /always/ bumping the value, when
things change. And changes in dependencies aren't limited to shared
library version bumps. For example, nobody sought to bump
PORTREVISION of mail/p5-FuzzyOcr-devel when gifinter-executable was
removed from graphics/giflib. The OCR plugin for SpamAssassin now
complains upon encountering interlaced GIF-attachments in spam...
* It is not always warranted -- x265 may be a default, but folks who
explicitly disabled its use by the tool do not need to rebuild their
ffmpeg now. And yet, they will have such a rebuild, because I just
bumped the PORTREVISION.
* It makes changes too broad -- x265 is used by few, but jpeg, for
example, touches almost everything under graphics/ and multimedia/
* It breaks compartmentalization -- a committer upgrading one port,
can bump PORTREVISION for depending ports /in the tree/ -- but not
for any privately-maintained ports. Tools need to keep track of this.
The new pkg-utility seems to keep track of shared libraries both
provided and required by each port. Any tool not taking advantage of
this needs fixing -- and we ought to stop attaching this second meaning
to the setting.
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f23cecfc-d669-e62b-1916-1e16e66fb3eb>