Misuse of PORTREVISION (Re: svn commit: r434379 - head/multimedia/x265)

Mikhail T. mi+thun at aldan.algebra.com
Sat Feb 18 21:56:56 UTC 2017


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




More information about the svn-ports-all mailing list