FFmpeg{-upstream} Portfiles seems to have an inordinate amount of dependencies? Is there a way to improve upon this?

[artkiver (グレェ)]

Hi there!

So I went to install FFmpeg and balked at the number of dependencies it wants to install.

e.g.

% port -v rdeps ffmpeg-upstream

(then copy and paste that output into a file and run wc:)

% wc
344     344   10972 

Or if running:

% port -v install
--->  Computing dependencies for ffmpeg...............................................................................................................................................................
The following dependencies will be installed:

(omitting 158 ports listed)

Continue? [Y/n]: 

Some of these, seem, *excessive* to understate it. kerberos5? rsync?

So, I decided to instead:

% git clone https://git.ffmpeg.org/ffmpeg.git
% cd ffmpeg 
% ./configure 
% make

Which seemed to function with 0 issues and produce a functional FFmpeg binary.

Taking this one step further, I decided to create my own Portfile, and see if this was much different, and no surprise: it wasn't.

Albeit, due to use of xz, the rdeps are still 8, but I am guessing even those could be whittled down if using a tar.gz instead of a .bz2?

% port -v rdeps
The following ports are dependencies of ffmpeg @5.1.2_0:
  bin:xz:xz
    port:gettext
      port:diffutils-for-muniversal
      port:libiconv
        port:gperf
      port:libtextstyle
        port:ncurses
      port:gettext-runtime
      port:gettext-tools-libs

Now, I am guessing probably a lot of things in the existing Portfile are maybe useful for older builds of OS X than Ventura?

Maybe there is some default variant stuff that is bringing along a lot of unnecessary cruft?

Obviously, there's also the +nonfree variant which focuses on things which shouldn't be redistributed, but even without that the default dependencies seem to be an awful lot.

Is there a way to turn that off some of this extra cruft and have a more minimal installation?

I mean, well, obviously the test Portfile I created is one possible way; but I mean more generally?

Thanks!

[artkiver (グレェ)]

A more minimal Portfile which seems to function A-OK on macOS Ventura, with far fewer dependencies.

[artkiver (グレェ)]

rdeps for existing FFmpeg which seem excessive

[artkiver (グレェ)]

FFmpeg dependencies as encountered on my system when running port -v install ffmpeg

[kencu (Ken)]

one of the deps requires rust, which brings in the flood…

the minute you remove a library dep to reduce the overall deps, someone else will say they really needed that library…

if you strip off deps into variants, then other ports have to dance to see if their needed ffmpeg variants are installed…

I think we leave it alone. Once the buildbot comes, you won’t usually see all the build deps anyway…

[artkiver (グレェ)]

Since there was some Rust related chatter on the macports-dev list, I mentioned this ticket there as well.

Sergey Fedorov replied as follows:

"FFMpeg can certainly be compiled without Rust, including the latest (upstream) version. Perhaps a component that is pulling in Rust should rather be made an optional variant for all systems – it is hardly justified to have it as the default, IMHO."

So, Sergey and I seem to be of a similar mindset. To be honest, I am not entirely sure why there are three separate FFmpeg ports especially since two of them are both an older version?

I suppose a ffmpeg-minimal is another possibility, but creating a 4th Portfile, when it seems as if it might be better to clean up the existing 3 separate, yet very closely related, ports might make more sense?

[kencu (Ken)]

the prebuilt intel version of ffmpeg for ventura is already on the packages server. The arm version will be soon coming.

rust is now needed for a number of ports, and it’s use is increasing steadily.

for context.

[artkiver (グレェ)]

Hi Ken, thank you for replying.

I think we may be contending with a miscommunication?

I am not interested in prebuilt versions and which architectures they are for, that is not the crux of the issue. Moreover, the CI build system still has Leopard G4/G5 systems in its tooling, so the fact that FFmpeg binaries are lacking for aarch64/Apple M1/M2 Silicon (which has now been out for over two years) while regrettable, seems as if it is also not relevant to what I wish to focus on in this ticket.

If Rust is needed now, for a number of ports, that also: seems irrelevant. It is *NOT* necessary to build FFmpeg from source from the upstream project.

So, that is not meaningful context.

If people need Rust, they should be installing Rust, not FFmpeg.

If people need FFmpeg and there is a variant which has Rust as a dependency, that variant, should NOT be a default.

Does that make it clearer?

I have already provided an example of a functioning Portfile for FFmpeg which does not require Rust. I will submit it as a PR for ffmpeg-devel if conversations continue this way, seeing how jeremyhu (whom I have already removed as a maintainer for libressl and libressl-devel) and the other port maintainers are not responding with anything meaningful nor pertinent. As it currently stands, there are 3 ffmpeg ports in the tree, when arguably at most there should be two (how is ffmpeg-devel different than ffmpeg-upstream for example?) and it is conceivable that even those could be reduced to one with proper use of variants.

[mascguy (Christopher Nielsen)]

Replying to artkiver:

To be honest, I am not entirely sure why there are three separate FFmpeg ports especially since two of them are both an older version?

ffmpeg-upstream tracks the latest release (currently 5.x). While ffmpeg-devel is used to validate pending changes to ffmpeg, before rolling out to everyone.

So yes, this is intentional.

I suppose a ffmpeg-minimal is another possibility, but creating a 4th Portfile, when it seems as if it might be better to clean up the existing 3 separate, yet very closely related, ports might make more sense?

We've considered various options, including adding more variants. But that quickly becomes a testing nightmare, due to the sheer number of combinations.

In short, there's simply no way to please everyone. Even today, there are open enhancement requests to add still more functionality.

So while you may prefer something simplified, that's at odds with others.

[kencu (Ken)]

clearly, I’m with Chris here.

Rust is inevitable these days.

Most users will just download the prebuilt ffmpeg binary, and never need to install rust anyway.

[artkiver (グレェ)]

Replying to mascguy:

Replying to artkiver:

To be honest, I am not entirely sure why there are three separate FFmpeg ports especially since two of them are both an older version?

ffmpeg-upstream tracks the latest release (currently 5.x). While ffmpeg-devel is used to validate pending changes to ffmpeg, before rolling out to everyone.

So yes, this is intentional.

Thank you for that clarification. I guess the delineation still makes zero sense to me, given that ffmpeg-devel is still public; and "rolling out to everyone" seems as if it would be a nomenclature perhaps more suitable for private branches and repositories than something within the MacPorts system?

At least in the instance of libressl as contrasted with libressl-devel, that appears to be related to the upstream project tagging some releases as Development and some releases as Stable; so it's a nomenclature from the upstream project, rather than an artifact of MacPorts' maintainer methodologies. Nonetheless, it's your bailiwick. I already offered one possible alternative.

I do not think a preference for minimalism and adherence to upstream defaults is an unusual preference, but I am not here to pick a battle.

I suppose a ffmpeg-minimal is another possibility, but creating a 4th Portfile, when it seems as if it might be better to clean up the existing 3 separate, yet very closely related, ports might make more sense?

We've considered various options, including adding more variants. But that quickly becomes a testing nightmare, due to the sheer number of combinations.

In short, there's simply no way to please everyone. Even today, there are open enhancement requests to add still more functionality.

So while you may prefer something simplified, that's at odds with others.

[artkiver (グレェ)]

Replying to kencu:

clearly, I’m with Chris here.

Rust is inevitable these days.

Most users will just download the prebuilt binaries, and never need to install rust anyway.

You got caught up in building rust because the Ventura builder was a bit delayed.

So, if I am interpreting this correctly, the implication is I hit an edge case because Apple Silicon binaries had not yet been generated by the buildbots?

Out of curiosity: what parameters are the buildbots using to generate such binaries? Is it different than %port install ffmpeg ?

It would be nice to know if I can generate similar binaries locally.

Thanks!