rpm-ostree update has been failing for the past few days with:
error: Could not depsolve transaction; 2 problems detected:
Problem 1: package libavdevice-free-6.1.1-12.fc40.x86_64 from @System requires libavcodec-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
- conflicting requests
Problem 2: package ffmpeg-free-6.1.1-12.fc40.x86_64 from @System requires libavfilter-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
- conflicting requests
These packages from RPMFusion keep causing these conflicts and blocking upgrades for weeks. Any workaround, or other repo I can use instead of relying on RPMFusion?
We would need the output of rpm-ostree status to be able to help. There are also a lot of thread around here about how to remove/replace the right amount of packages for codec support.
error: Could not depsolve transaction; 3 problems detected:
Problem 1: package libavdevice-free-6.1.1-12.fc40.x86_64 from @System requires libavcodec-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
- conflicting requests
Problem 2: package ffmpeg-free-6.1.1-12.fc40.x86_64 from @System requires libavfilter-free(x86-64) = 6.1.1-12.fc40, but none of the providers can be installed
- conflicting requests
Problem 3: package mesa-va-drivers-freeworld-24.0.5-1.fc40.i686 from rpmfusion-free requires mesa-filesystem(x86-32) = 24.0.5, but none of the providers can be installed
- conflicting requests
- mesa-filesystem-24.0.5-1.fc40.i686 from fedora does not belong to a distupgrade repository
- package mesa-va-drivers-freeworld-24.0.5-1.fc40.x86_64 from rpmfusion-free requires mesa-filesystem(x86-64) = 24.0.5, but none of the providers can be installed
- package mesa-va-drivers-freeworld-24.0.7-1.fc40.x86_64 from rpmfusion-free-updates requires mesa-filesystem(x86-64) = 24.0.7, but none of the providers can be installed
- cannot install both mesa-filesystem-24.0.5-1.fc40.x86_64 from fedora and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
- cannot install both mesa-filesystem-24.0.7-1.fc40.x86_64 from updates-archive and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
- cannot install both mesa-filesystem-24.0.7-3.fc40.x86_64 from updates-archive and mesa-filesystem-24.0.8-1.fc40.x86_64 from @System
- nothing provides mesa-filesystem(x86-32) = 24.0.7 needed by mesa-va-drivers-freeworld-24.0.7-1.fc40.i686 from rpmfusion-free-updates
The mesa conflict is to be expected as the fedora mesa maintainers refuse to coordinate with rpmfusion.
It isn’t reasonable to expect rpmfusion to respond to such quick non-critical updates, 21 hours from submission to stable.
Well, I haven’t been able to update since May 17 because of this. Which is unfortunate because I need to update another package, and the only workaround is unlayer the entire rpmfusion package set, update and when this is fixed, add it back again.
Do we have a rough ETA of how long the rpmfusion stays out of sync? If it’s another week, I’ll go through with it.
The ffmpeg conflict issue should be reported against rpm-ostree, it’s a fedora problem.
I signed and pushed the rpmfusion update today, this is done about once a week.
Yes, that’s how I installed all the RPMFusion codecs in the first place.
Still unable to update. I reckon I should look into ublue as they deal with all this codec packaging nonsense… too bad they have redesigned their website and it’s impossible to find the URL to rebase to.
The Rpmfusion founders made some basic rules when they formed the repo.
The non package replacement policy is now dated since fedora started shipping it’s crippled versions.
Using package replacement would be much easier for users.
I just migrated to vanilla Universal Blue that deals with this RPMFusion packaging nonsense itself.
As no one seems to take responsibility for this interaction (also opened an issue on the Silverblue repo, which was closed because rpmfusion ain’t their problem), any time there’s a ffmpeg update there’s gonna ostree update issues. Worth looking into ublue (which is pretty much just Silverblue with codecs and extra goodies included) if it happens again.
With vanilla uBlue, do you mean their " main " image, this one?
I noticed just rebasing didn’t work, some error messages, but the documentation of uBlue indicates you should start with a fresh Silverblue first then rebase, so I’ll do that just in case.
If you have any other related recommendations please share.