Passing dnf options to rpm-ostree update? Avoid conflict with rpmfusion for mesa

Ask Fedora
, , ,
1

I cannot update Silverblue due to conflict with mesa-va-drivers-freeworld / mesa-filesystem at the moment. This is the error message:

Failed to download updates: Could not depsolve transaction; 1 problem detected:
 Problem: package mesa-va-drivers-freeworld-26.0.3-1.fc44.i686 from rpmfusion-free requires mesa-filesystem(x86-32) = 26.0.3, but none of the providers can be installed
  - conflicting requests
  - mesa-filesystem-26.0.3-4.fc44.i686 from fedora does not belong to a distupgrade repository
  - package mesa-va-drivers-freeworld-26.0.3-1.fc44.x86_64 from rpmfusion-free requires mesa-filesystem(x86-64) = 26.0.3, but none of the providers can be installed
  - cannot install both mesa-filesystem-26.0.3-4.fc44.x86_64 from fedora and mesa-filesystem-26.1.8-1.fc44.x86_64 from @System
  - nothing provides mesa-filesystem(x86-32) = 26.2.2 needed by mesa-va-drivers-freeworld-26.2.2-2.fc44.i686 from rpmfusion-free-updates
  - nothing provides mesa-filesystem(x86-64) = 26.2.2 needed by mesa-va-drivers-freeworld-26.2.2-2.fc44.x86_64 from rpmfusion-free-updates

The cause seems to be that:

  1. The Fedora package mesa-filesystem is available in version 26.1.8-4.fc44 (see package database)
  2. I have mesa-va-drivers-freeworld installed as layered package on top of the Silverblue deployments.
  3. The RPMFusion package mesa-va-drivers-freeworld is available in version 26.2.2 according to the spec file on RPMFusion

As a workaround, with dnf (i.e., on a non-atomic Fedora edition), I would either use the --skip-broken flag for skipping the update of mesa-va-drivers-freeworld, or I would use --enablerepo=updates-testing to update mesa-filesystem. However, I don’t know how to apply any of these in rpm-ostree.

I have tried modifying the /etc/dnf/dnf.conf to excludepkgs=mesa-va-drivers-freeworld, but it seems like rpm-ostree doesn’t respect that file or setting and I couldn’t find any other way of setting this option, e.g. via command line.

As a temporary workaround, I can execute rpm-ostree update --uninstall=mesa-va-drivers-freeworld and as soon as the package would be available, I could execute rpm-ostree install mesa-va-drivers-freeworld to install it again.

Also, I would like to have this problem solved in a more generic, persistent way. Do you have any ideas for that?

This issue has happened before. Would it make sense to ask the rpmfusion maintainers to loosen version dependencies from mesa-va-drivers-freeworld onto the mesa-filesystem package?

Also, it would be nice if I could install beta updates on fedora atomic to contribute by testing packages and giving karma.

PS: This issue has been described before by @ntexplorer and a few other users here.

2

Remove the package mesa-va-drivers-freeworld then update. If you wish that package can be reinstalled after the update (as soon as the matching fedora packages are released.) The mesa packages version 26.2.2 are in the fedora updates-testing repo so they should be available very soon.

This issue is a matter of timing when packages are released in 2 completely different repos. Fedora repos and rpmfusion repos are maintained by different entities and it is difficult to perfectly coordinate the timing of package version releases.

This repo timing issue occurs quite often and the simplest and most problem free solution is to wait a few days before performing updates to allow time for the repos to come in sync with the package versions.

No. The package versions must match since there are often unseen changes that would break things when different versions were intermingled.

3

I’ve also seen this situation once or twice on Silverblue, when RPM-Fusion was involved. As @computersavvy mentioned, it’s most probably caused by timing issues between Fedora and RPM-Fusion repos.

With atomic desktops there is an additional piece in the puzzle as I see it: the base image is built on Fedora’s infrastructure AFAIK, with up-to-date packages, while a need for layering will search for Fedora dependency packages on the mirror chosen by the system, which might not be as up-to-date and be causing depsolve issues.

You could rebase to the testing branch of Silverblue, but I’m not sure if this is what you expect (the full ostree image on testing packages), or you’d rather like to only install specific packages from updates-testing. There is no --enable-repo counterpart for the rpm-ostree commands AFAIK. You could use rpm-ostree override replace which also takes HTTP file paths as arguments, but it’s not as flexible as dnf[1].

OTOH, with atomic desktops once has the option to have both branches (stable and testing) as deployments (with the non-default entry pinned), and switch between them as needed.

Regarding the original issue, I don’t need to layer RPM-Fusion multimedia packages on my Silverblue installations anymore, as I have switched to Flatpaks from Flathub.

  1. IIRC, one has to provide dependent packages explicitly. ↩︎

4

Done that. However, I was thinking of a more permanent (lower maintenance) option to fulfil the following criteria:

  • Update mesa whenever possible
  • When mesa dependencies are broken, still update the base image (even if this comes at the cost of uninstalling some rpmfusion packages)

Due to security updates, I’d like to not wait the issue to be fixed. (how) is that possible?

It would be nice to only test specific packages, not switch to a full testing ostree image.

Thanks for the hint, however I feel like this is too inconvenient to actually be used, especially for this use case.

Don’t you need hardware accelerated video decoding? Or do you only use video with flatpak applications that bring their own libva (either in their package, or in the runtime)?

5

I am only using multimedia apps from Flathub, including Firefox[1], and those only need the org.freedesktop.Platform.codecs-extra runtime, which usually gets installed as a runtime extension. Therefore, I don’t need to layer multimedia RPMs from RPM-Fusion on top of my OSTree image.

  1. Actually, I have fully switched to Flathub as the single source of Flatpaks. ↩︎

6

Thanks for sharing your experience!