Simplifying updates for RPM Fusion packages (and other packages shipping their own RPM repos)

Sorry, I did this and it worked, but I dont understand how.

1) How does ostree know what to do first? Doesnt it parse the command from the beginning to end? Does it know that it has to first install the new packages, then remove the the old .noarch ones, if so, how is it that “intelligent”?

2) Most important question: Another user asked this but the answer wasnt quite satisfactory - where do the versionless packages come from? They are NOT available on rpmfusion!
There are three packages available for each version (free/non-free) and here they are:

rpmfusion-nonfree-release.noarch : RPM Fusion (nonfree) Repository Configuration
rpmfusion-nonfree-release-rawhide.noarch : RPM Fusion Rawhide nonfree repo definitions
rpmfusion-nonfree-release-tainted.noarch : RPM Fusion nonfree Tainted repo definition

Thats it. No “rpmfusion-nonfree-release” with nothing else coming after the name, so let me repeat: Where do these packages come from? I googled too, but all I was getting for “versionless rpmfusion packages” was this forum post … I dont understand :slight_smile:

Thanks!

Sorry for the bump in the old thread, but Id really like to understand, could you have a look at my last post? Thanks!

I will try to explain.

If you are referring to the step below, yes, rpm-ostree will parse it top to bottom.

Not sure what you are referring to when you say “first install the new packages”. But yes, before running the code above, you need to follow the instructions as mentioned:

As for your second question…

At first you have a fresh system - never had RPM Fusion installed before. You have no rpmfusion-*.repo files installed in /etc/yum.repos.d. Fedora does not host any rpmfusion .rpm packages in their repositories, therefore you need to fetch those directly from rpmfusion.org running:

sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

So that fetches the .rpm file from the mirror and installs the contents; which are basically the rpmfusion-*.repo files in /etc/yum.repos.d.

Now rpm-ostree tracks that there are overlays installed (of the rpmfusion rpms) - you can see them if you run rpm-ostree status - it will say:
LayeredPackages: rpmfusion-free-release-34.0.3.noarch rpmfusion-nonfree-release-34.0.2.noarch

To understand the problem, let’s look at a completely different example: say you want to overlay emacs. You would simply execute rpm-ostree install emacs. The emacs packages is sourced from the fedora-updates repo. The fedora-updates.repo file in /etc/yum.repos.d already accounts for the release (f34) and architecture (x86_64), so it will fetch from the repo mirrors the file emacs-27.2-11.fc36.src.rpm. Notice now that if you run rpm-ostree status to query the LayeredPackages it lists “emacs”, not “emacs-27.2-11.fc36.src.rpm”. When an upgrade is performed to the BaseCommit, the Layered Packages are queried again against the known repos, fetched, and upgraded.

Now going back to the RPM Fusion overlays. Why do those overlays have the “*-34.03.noarch” suffix? Because they weren’t queried against a repo using the base name (e.g. - “emacs” or “rpmfusion-free-release”), but rather we had to give it the explicit rpm source address and filename (https://mirrors.rpmfusion.org…noarch.rpm). We couldn’t query the base name because “rpmfusion-free-release” didn’t exist in any known/installed repos yet. And rpm-ostree status lists the complete filename because it doesn’t know any better.

But once we installed it the first time, we now have the rpmfusion-*.repo files installed in /etc/yum.repos.d. And so we run the rpm-ostree uninstall rpmfusion-free-release-34.0.3.noarch. This removes the Layered Package, but remember in ostree, changes aren’t committed until reboot! So the rpmfusion-*.repo files still exist in /etc/yum.repos.d. This lets us do the second part, which is the rpm-ostree install rpmfusion-free-release. Now we are querying the repos using the base name, just like we did with “emacs”. And the repo that has that base name is the previously installed, and not-yet-uninstalled, rpmfusion-*.repo.

Now that all the pieces are in place: since the Layered Package is listed under the base name, not the explicit rpm file name, when an upgrade in performed, it will query the repos using the base name and correctly return the latest version appropriate for the system’s version and architecture.

1 Like

Thank you for that very in-depth answer and that you took the time to write it - I understood now.

I tried to explain this myself, but failed, since I missed an important detail.

All layered packages are “versionless”, while the local one has a version number. If I didnt miss this, I wouldnt have scratched my head for two weeks :grinning:

Thanks again!

This solution works with a couple of modifications for Fedora Silverblue 36 users who upgraded from 35. Note that there’s a dash where a dot used to be, as well as the updated version number:

rpm-ostree update \
            --uninstall rpmfusion-free-release-36-0.2.noarch \
            --uninstall rpmfusion-nonfree-release-36-0.2.noarch \
            --install rpmfusion-free-release \
            --install rpmfusion-nonfree-release

Note: Check your RPM Fusion repo versions and adjust this command if needed before running it.

1 Like

All this said, upgrading from 35 to 36 Beta with RPM Fusion repos required a lot more manual intervention than I like.

If I’m still on Silverblue when 37 comes out, I will be waiting until maybe a couple of weeks after the release before upgrading.

Can we have a version that verify which rpm NVRA are installed (layered ?) and

That so I can copy a “stable” version in the RPM Fusion wiki ? (referencing this post for credits).

Thanks in advance.

I’ve verified that the following suggestion works in a fresh Fedora Silverblue virtual machine:

# Install RPM Fusion repos
$ sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
$ reboot

# Replace the versioned local packages by overlayed packages from the repo
$ sudo rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
$ reboot

Note that this applies to all rpm-ostree variants of Fedora: Fedora Kinoite, Fedora IoT and Fedora CoreOS.

However, it’s more likely to be used on Fedora Silverblue and Kinoite thus listing those two would be great.

Thanks!

(post deleted by author)

@kwizart Gentle ping. Let me know if I can help you to update the RPM Fusion instructions on the wiki.

Thanks for the reminder.

The topic was raised at 6485 – Broken silverblue/coreos automatic system upgrades: documentation needs changing
I’ve updated various doc on the wiki, specially this one was created:
Howto/OSTree - RPM Fusion

Hope this helps

That been said, about the rpm-ostree update uninstall/install dance:
I really think this is “an evil miss-design” that really need to be fixed at upstream rpm-ostree

That so graphical tool users don’t even have to bother… (and the documentation on this particular point can be dropped).

Thanks for the update. I agree that the experience is not great but it’s what we have right now.

Note that the second command should be done right away after the first installation and will only be needed once:

# Replace the versioned local packages by overlayed packages from the repo
$ sudo rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release
$ reboot

All updates after that will just happen naturally.

I there upstream report on this?

I have always installed the Fusion repos in a toolbox. They are not layered packages on any of my systems, and seem to work just fine from within the toolbox. Packages get added and show up in the menu. Was this not a better way to keep the layered packages count low?

I only have four layered packages:

akmod-nvidia gstreamer1-plugin-openh264 mozilla-openh264.x86_64 xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda

What drawbacks would doing it this way have on packages in the CoreOS getting updated. Aren’t all those packages RPM’s from Fedora-Linux?