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

[guiltydoggy (Yosuke)]

I will try to explain.

@spicysauced

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”?

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

@siosm

$ sudo rpm-ostree update \
            --uninstall rpmfusion-free-release-34.0.3.noarch \
            --uninstall rpmfusion-nonfree-release-34.0.2.noarch \
            --install rpmfusion-free-release \
            --install rpmfusion-nonfree-release

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:

@siosm

The first time you install RPM Fusion, you should follow the official guide: Configuration - RPM Fusion

As for your second question…

@spicysauced

2) Most important question: Another user asked this but the answer wasnt quite satisfactory - where do the versionless packages come from?

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.