From owner-svn-ports-all@freebsd.org Sat Feb 18 21:56:55 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E75C3CE4A36 for ; Sat, 18 Feb 2017 21:56:55 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3B5F188E for ; Sat, 18 Feb 2017 21:56:55 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=C6ir8kH+ c=1 sm=1 tr=0 a=lGUdY1O6J9NpztYPi32J9g==:117 a=lGUdY1O6J9NpztYPi32J9g==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=CQPQxerWaudb6mZHNGYA:9 a=pILNOxqGKmIA:10 a=6I5d2MoRAAAA:8 a=5DjKkigddAFwX6gm7kQA:9 a=AGeIGf_YCz8xMtNf:21 a=_W_S_7VecoQA:10 a=IjZwj45LgO3ly-622nXo:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: YW5hdEByY24uY29t Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=mi+thun@aldan.algebra.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=mi+thun@aldan.algebra.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=anat; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 108.53.87.28 is neither permitted nor denied by domain of aldan.algebra.com) Received: from [108.53.87.28] ([108.53.87.28:50667] helo=aldan.narawntapu) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPSA (cipher=DHE-RSA-AES128-SHA) id DA/C4-25503-023C8A85; Sat, 18 Feb 2017 16:56:48 -0500 Subject: Misuse of PORTREVISION (Re: svn commit: r434379 - head/multimedia/x265) To: Jan Beich , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org References: <20170218210541.82AA915F6@freefall.freebsd.org> From: "Mikhail T." Message-ID: Date: Sat, 18 Feb 2017 16:56:46 -0500 MIME-Version: 1.0 In-Reply-To: <20170218210541.82AA915F6@freefall.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 21:56:56 -0000 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