Re: git: 7ebddd96d372 - main - multimedia/mlt7*: Update to 7.18.0

Jason E. Hale wrote:
> On Mon, Jul 31, 2023 at 5:56 PM Charlie Li <vishwin@freebsd.org> wrote:
>>
>> Jason E. Hale wrote:
>>> I think the most sensible approach would be to handle the ebur128
>>> dependency similar to librsvg2 and pycryptography. It would be trivial
>>> to create a Mk/Uses/ebur128.mk and allow the user to set whether they
>>> wanted to use the legacy C implementation via DEFAULT_VERSIONS in
>>> /etc/make.conf. The rust version would still be the default, however.
>>> Does that sound like an agreeable solution?
>>>
>> Not really.
>>
>> The librsvg2 and py-cryptography arrangements exist due to being
>> fundamental components of many consumers of wide-ranging general use
>> cases. Not having librsvg2 wipes out desktop and some (web) graphics
>> support, and no py-cryptography eliminates nearly any Python package or
>> consumer using SSL/TLS/X.509. ebur128 doesn't come close to those
>> impacts, and thus an additional USES is not worth the cost.
>>
> 
> I'm curious as to what cost would it add other than an extra 1494
> bytes of space to everyone's ports tree and my spare time, as I've
> already implemented it.
> 
Specific byte counts or implementation details are not created equal. 
Rather, the approach towards this conjecture is problematic: we can't be 
entertaining "knobs" for every port that, originally implemented in C or 
C++ or some other "lighter-weight" language compiled or not, switches or 
grows another implementation in [newer self-hosting compiled language 
with its own bootstrap process and maybe a kitchensink]. While 
exceptions always exist (the two mentioned before), this isn't one of 
them. Too many of these even in the short term results in future ports 
people having to deal with debt and junk.
>> By contrast, multimedia, especially on the creation/rendering/mixing
>> side, is not nearly a general use case compared to those aforementioned.
>> Since this thread is about MLT in particular, there is no need for any
>> special treatment here, since MLT and its consumers are not designed or
>> intended to be built or ran on insufficiently-resourced computingues.
>> environments.
>>
> 
> That's understandable, but vdv@ seems to have had the resources before
> this change, otherwise would not be raising the issue.
> 
Not my read. This reeks more of a fundamental misunderstanding of 
dependency selection and logic, which more easily happens when strictly 
commenting on code without further context.

-- 
Charlie Li
…nope, still don't have an exit line.