From owner-svn-ports-all@freebsd.org Wed Sep 23 20:47:10 2020 Return-Path: Delivered-To: svn-ports-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1EF12426679; Wed, 23 Sep 2020 20:47:10 +0000 (UTC) (envelope-from mi+t@aldan.algebra.com) Received: from symbion.zaytman.com (symbion.zaytman.com [64.112.176.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "symbion", Issuer "Narawntapu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxVbc6PkJz4LPN; Wed, 23 Sep 2020 20:47:08 +0000 (UTC) (envelope-from mi+t@aldan.algebra.com) Received: from narawntapu.narawntapu (pool-96-234-76-140.nwrknj.fios.verizon.net [96.234.76.140]) by symbion.zaytman.com (8.16.1/8.15.2) with ESMTPS id 08NKl1GM015453 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Sep 2020 16:47:02 -0400 (EDT) (envelope-from mi+t@aldan.algebra.com) X-Authentication-Warning: symbion.zaytman.com: Host pool-96-234-76-140.nwrknj.fios.verizon.net [96.234.76.140] claimed to be narawntapu.narawntapu Received: from aldan.narawntapu (aldan [192.168.3.13]) by narawntapu.narawntapu (8.16.1/8.15.2) with ESMTP id 08NKkw0R085153; Wed, 23 Sep 2020 16:46:58 -0400 (EDT) (envelope-from mi+t@aldan.algebra.com) X-Authentication-Warning: narawntapu.narawntapu: Host aldan [192.168.3.13] claimed to be aldan.narawntapu Subject: Re: svn commit: r549657 - in head: graphics/digikam graphics/libbpg graphics/libheif multimedia/ccextractor multimedia/emby-server multimedia/ffmpeg multimedia/gstreamer1-plugins-x265 x11/xpra To: Baptiste Daroussin Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org References: <202009230417.08N4HCAn072615@repo.freebsd.org> <20200923065315.6xaqwxvljkhj646s@ivaldir.net> From: "Mikhail T." Message-ID: Date: Wed, 23 Sep 2020 16:46:58 -0400 MIME-Version: 1.0 In-Reply-To: <20200923065315.6xaqwxvljkhj646s@ivaldir.net> Content-Language: en-US X-DCC-x.dcc-servers-Metrics: narawntapu 104; bulk rep Body=4 Fuz1=4 Fuz2=4 rep=63% X-Spam-Status: No, score=2.7 required=23.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,IMPRONONCABLE_2,RATWR8_MESSID,TW_SV,WINDOWS_7BITS autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on narawntapu.narawntapu X-Rspamd-Queue-Id: 4BxVbc6PkJz4LPN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mi@aldan.algebra.com has no SPF policy when checking 64.112.176.10) smtp.mailfrom=mi@aldan.algebra.com X-Spamd-Result: default: False [-1.46 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mi]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[algebra.com]; AUTH_NA(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_LONG(-0.86)[-0.865]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.71)[-0.713]; NEURAL_HAM_SHORT(-0.78)[-0.785]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:394548, ipnet:64.112.176.0/24, country:US]; TAGGED_FROM(0.00)[t]; MAILMAN_DEST(0.00)[svn-ports-head,svn-ports-all]; RECEIVED_SPAMHAUS_PBL(0.00)[96.234.76.140:received] Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.33 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: Wed, 23 Sep 2020 20:47:10 -0000 Look in the archives for the thread titled "shlib-induced PORTREVISION chases". Started in 2008, it contains acknowledgements of the problem, as well as things like: The problem isn't pkg or poudriere---they do the right thing (and I wish I'd mentioned that earlier: what you're talking about IS the right thing to do). The problem is that we have to target the lowest common denominator, which at this point is portupgrade and portmaster (not to mention make(1) itself). If we could count on all the various build tools actually rebuilding the ports they should be, I would be *thrilled* to see PORTREVISION bumps disappear. Whether these things count as a "promise" to address the problem or not, it is a problem. One well known for many years, yet still present. And, being one of the ports-building "system" -- rather than of a particular port -- solving it is squarely on portmgr. That thread currently ends with my message from July 17, 2018, ID <0ec15ef9-1386-7ad2-21ca-a8066686eb06@aldan.algebra.com>, which remains unanswered since... Would you like to reply to it now? Respectfully, -mi On 23.09.20 02:53, Baptiste Daroussin wrote: >> Log: >> For well over 10 years portmgr@ have been promising to remove the >> ridiculous need to bump PORTREVISION of depending ports, whenever a >> dependency is updated, but here we still are... >> >> Bump PORTREVISION for the 9 users of x265 now that it has been >> upgraded from 3.2 to 3.4. >> > I have been in portmgr@ for around 10 years such promise has never been made! > > It would be nice to refrain sarcastic comments like this one! > > Aside from that it is up to everyone to work on the infrastructure, portmgr is > there to ensure it is done a consistent way, it is not up to portmgr to do the > work, it appears some members of portmgr are often doing the infrastructure work > but that is all. > > That said the number of bumps that are required have been reduced a lot in the > last 10 years, and the fact that the SOVERSION of a library changes makes it > requires the bump as it changes the binaries linked to it! > If you have a technically working idea on how to automate those bumps be our > guess, propose a patch. In the mean time I would really appreciate if you could > be a bit more respectful.