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:
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
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 norpmfusion-*.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:
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.
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:
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).
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?
