I’m sharing here a tip that I’ve just found to make it simpler for major update for RPM Fusion users on Silverblue and other rpm-ostree based variants.
But then, once you have rebooted into the new deployment, you can run the following command to remove the “lock” on a specific version of the packages (this is essentially removing the fixed version packages and installing the non-versioned ones in the same transaction):
I have not tested that yet across a major version rebase, but I’m hopeful that this should work. This will at least keep those packages updated for a given version, which is already better than what I had before.
Note that this also work with the Google Chrome RPM package which includes its own RPM repo.
My regular setup is the rollback here, and pinned because virt-manager stopped working they day after that, but that’s a story for a different post when I get to it.
Anyway, I get the same thing with only the free package installed as normal, but switched to your setup with both free and nonfree packages to check if it would make a difference.
Whenever I run rpm-ostree status and see those versioned rpm fusion packages - I always wondered what would happen to them when i upgrade to SB 35 sometime in the future. I was expecting I might need to do some manual fix up…
I’m glad you’ve answered that for me ahead of time!
I’m curious though, what happens if we don’t “unpin” those packages before doing the SB 34 to 35 upgrade?
It was necessary to replace the local package of rpmfusion in the same commit to avoid errors with rpm-ostree being unable to find the next releases (still-requested) rpmfusion-provided overlay packages.
The longer alternative was to reset overrides, rebase, add the new local packages and re-overlay packages.
This looks sensible as a correct fix for this process. (rebasing layered rpm along the baseos).
But then you will have to reproduce on any rpmfusion packages that is installed via rpm-ostree (specially thoses that have any deps changes from the base fedora distribution).
So to me it sounds like the rpmfusion-*release rebase issue is the tree hiding the whole forest (you have a bigger problem behind). The google-chrome are not good example as they are distro agnostic.
If any ostree/Silverblue involved developer are kind enough to escalate to bugzilla.rpmfusion.org I’m sure we can draft a barely usable solution that can work as expected everywhere.
I’m not sure I follow the issue here. Other packages installed from the rpm-fusion repos via rpm-ostree install will be updated if needed during each system update as their versions are not pinned.
This workaround is only needed here as the initial installation from RPM packages is pinning the version of the packages.
Didn’t work for me somehow. Had done the above command with fedora 33. But after rebase to 36, the upgrade complained about rpmfusion-free-release-…36 not being found or something. Had to do a