Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 2020 16:46:58 -0400
From:      "Mikhail T." <mi+t@aldan.algebra.com>
To:        Baptiste Daroussin <bapt@FreeBSD.org>
Cc:        ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org
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
Message-ID:  <fa938c67-fe34-60ec-44a1-a498e67ce60b@aldan.algebra.com>
In-Reply-To: <20200923065315.6xaqwxvljkhj646s@ivaldir.net>
References:  <202009230417.08N4HCAn072615@repo.freebsd.org> <20200923065315.6xaqwxvljkhj646s@ivaldir.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fa938c67-fe34-60ec-44a1-a498e67ce60b>