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

From: Jason E. Hale <jhale_at_freebsd.org>
Date: Tue, 01 Aug 2023 00:05:31 UTC
On Mon, Jul 31, 2023 at 5:56 PM Charlie Li <vishwin@freebsd.org> wrote:
>
> Jason E. Hale wrote:
> > On Sun, Jul 30, 2023 at 9:15 PM Vladimir Druzenko <vvd@freebsd.org> wrote:
> >> The need has arisen.
> >>
> >
> > 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.

> 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.

-Jason