ffmpeg_4: almost drop #336401
ffmpeg_4: almost drop #336401
Conversation
emilazy
requested review from
K900,
NickCao,
SuperSandro2000 and
ttuegel
as code owners
emilazy
force-pushed
the
push-ssnkmyzwzysn
branch
from
fe8deea to
4357940
Compare
Builds fine with FFmpeg 7, and Arch ships it like that.
This builds with FFmpeg 6, but still needs updating for FFmpeg 7.
This builds fine with the newer version. There are apparently no plans to support FFmpeg 7.
Includes fixes for FFmpeg 7.
Includes fixes for FFmpeg 7.
Includes fixes for FFmpeg 6. This is another `ffmpeg-sys-next` fork situation that is going to be a pain when we bump to 7.
Includes fixes for FFmpeg ≥ 5.
Includes fixes for FFmpeg 7.
emilazy
force-pushed
the
push-ssnkmyzwzysn
branch
from
4357940 to
778806c
Compare
|
This is now just pending on the If I don’t hear back from the |
There was a problem hiding this comment.
Should the 24.11 release notes be edited to no longer recommend pinning ffmpeg_4?
|
I’m planning to fold the FFmpeg 5 removal note into the one about FFmpeg 7 becoming the default, and add more warnings about FFmpeg 4 there when I do that PR, since otherwise I’d be writing something about FFmpeg versions just to rewrite it again a few days from now. (And, anyway, we’ll still have a couple binary packages pinning |
|
With all the other PRs dealt with, this is now ready for review and merge 🎉 |
|
By the way, we could actually drop |
|
@SuperSandro2000 could you not unassign maintainers of the package the PR is about and merge without notice? Thanks. |
|
Often people are assigned by accident to PRs because they don't know that we only really use reviews. From the thread there is no clue about the assigned should be doing and the PR is not about ffmpeg which you maintain but about usages which didn't where updated in the last years. |
|
@SuperSandro2000 I am also one of the FFmpeg maintainers, precisely as a result of this months‐long project to get rid of old versions. You think I accidentally pinged my co‐maintainers to the latest PR in my long‐running FFmpeg project? I’m sorry, but assuming I made some beginner’s mistake in asking for review here with the amount of care and effort I’ve put into this project is just incredibly condescending. (Well, okay, yes: it was accidental that I added them as assignees and not reviewers, but what does that matter? If that’s a big deal, you could remove them as assignees and add them back as reviewers instead.) It’s very much about FFmpeg – look at the title! – and contains an FFmpeg policy decision that I specifically wanted their sign‐off on, not to mention my talk of potentially dropping one of the FFmpeg packages in the comment immediately before your merge without comment. Did you even read the PR? I’ve been coordinating this whole project with them. Can you just admit you screwed up here rather than deflecting and making excuses…? @Atemu @jopejoe1 I am sorry about this, and of course still open to any feedback here. |
|
Oh well derp sorry. |
|
Sandro, all of us have been Nixpkgs maintainers for many years. We know how things work around here. It's true that we don't use assignment often (we really should) but if we do, the meaning should be very obvious: The people assigned are responsible for whatever they're assigned to and thereby "own" it. In this case, Emily didn't appear to technically mean to do that but something slightly different but the intention would have been the same. I think that we should make these rules more explicit for clarity but don't you think it's at least worth asking when a situation is, in your opinion, unclear? As a maintainer, I feel disregarded here and I regret showing support of restoring your merge privilege a little. For the record, I generally agree that we should depend on ffmpeg_4 as little as possible but I wouldn't go as far as banning its use in source packages. I'd prefer if people attempted to patch their packages for compat but it shouldn't block the package's inclusion (SHOULD) as I think that, while it's reasonable to ask people to patch their package in such a way, you cannot expect them to do so. Emily went above and beyond to patch these packages in a way we cannot expect any maintainer to do so IMHO. |
|
I can agree that it’s more of a SHOULD than a MUST. That said, in my experience the packages that actually needed patching (rather than just updating or undoing a pin) were almost universally ones that were pretty crusty and hadn’t seen any upstream activity in many years. (The exceptions were mostly packages that seemed to be moving away from using FFmpeg at all, or stuff like Qt WebEngine – though even there it was a symptom of WebEngine being based on an old Chromium and needing the FFmpeg 7 patches from Chromium upstream backporting.) My assessment was that it would be questionable to add those packages that needed non‐trivial work in 2024. We couldn’t add a package that depends on versions of FFmpeg older than 4 without patching, but even with patching I think it would give us pause – do we really want to add something to the tree that it seems clear off the bat is not going to get any upstream maintenance to deal with any future issues? As a result it seemed unlikely to me that there’d be a compelling new source package that can’t support FFmpeg 6+, and that we shouldn’t add more baggage that will make it harder to drop the version when the lagging binary packages finally catch up. I’m happy to reword the message if you think I could capture those nuances better, or discuss it further if there’s still disagreement. |
|
Another bit of colour I should add is that many of the packages could easily have been bumped from FFmpeg 4 to FFmpeg 6 with just an unpinning and perhaps an update – part of why this was so much effort is that I tried to get things on the newer FFmpeg 7 if possible to smooth over the upcoming default version migration rather than turning 6 into the new 4. So since depending on FFmpeg 6 for a new package is reasonable (if perhaps suboptimal), even a large portion of the packages that required some active work on my part would have been able to be added without any issues or patching. |
Description of changes
Bump almost all of the remaining dependencies on FFmpeg 4, and add a comment about its legacy status so that we can discourage further proliferation and hopefully remove it at some point.
This PR is stacked on top of the following others; please ensure any remaining PRs are reviewed and merged before landing this one:
All of the package changes that are in any way tricky or potentially controversial were split out into the above PRs. This home straight consists entirely of trivial changes of FFmpeg pins, bumps between upstream versions of the same stability level, and clean backports of simple patches that have already been committed upstream. Everything here has been confirmed to build.
After this PR and the linked ones, the remaining packages depending on
ffmpeg_4will be:reaper(binary package; dependent on upstream’s whims)spotify(binary package; dependent on upstream’s whims)rocmPackages_{5,6}.mivisionx(both broken for a long time; maybe they’ll update before they become unbroken!)This turned out to be a bigger project than I thought it would be when I started out, but 34 PRs later, I’m glad to finally see it (almost) completed.
Once all of these PRs are merged, I am going to bump
ffmpegto 7 onstaging, and the real fun can begin.Result of
nixpkgs-reviewrun on aarch64-linux 11 package marked as broken and skipped:
1 package failed to build:
27 packages built:
Result of
nixpkgs-reviewrun on x86_64-linux 11 package failed to build:
30 packages built:
Result of
nixpkgs-reviewrun on aarch64-darwin 11 package marked as broken and skipped:
3 packages built:
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.