Opened 2 years ago
Last modified 2 years ago
#66424 new enhancement
FFmpeg{-upstream} Portfiles seems to have an inordinate amount of dependencies? Is there a way to improve upon this?
Reported by: | artkiver (グレェ) | Owned by: | |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | mascguy (Christopher Nielsen), dbevans (David B. Evans), jeremyhu (Jeremy Huddleston Sequoia) | |
Port: | ffmpeg |
Description
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!
Attachments (3)
Change History (12)
Changed 2 years ago by artkiver (グレェ)
Attachment: | Portfile.moreminimal added |
---|
Changed 2 years ago by artkiver (グレェ)
Attachment: | ffmpeg_rdeps added |
---|
rdeps for existing FFmpeg which seem excessive
Changed 2 years ago by artkiver (グレェ)
Attachment: | ffmpeg_dependencies added |
---|
FFmpeg dependencies as encountered on my system when running port -v install ffmpeg
comment:1 Changed 2 years ago by jmroot (Joshua Root)
Cc: | mascguy dbevans jeremyhu added |
---|---|
Milestone: | MacPorts Future |
Port: | ffmpeg added |
Type: | request → enhancement |
comment:2 Changed 2 years ago by 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…
comment:3 follow-up: 6 Changed 2 years ago by 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?
comment:4 Changed 2 years ago by 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.
comment:5 Changed 2 years ago by 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.
comment:6 follow-up: 8 Changed 2 years ago by 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.
comment:7 follow-up: 9 Changed 2 years ago by kencu (Ken)
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.
comment:8 Changed 2 years ago by 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). Whileffmpeg-devel
is used to validate pending changes toffmpeg
, 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.
comment:9 Changed 2 years ago by 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!
A more minimal Portfile which seems to function A-OK on macOS Ventura, with far fewer dependencies.