rpm-ostree does not read `/usr/lib/yum.repos.d` [update: ticket belongs in libdnf]
Opened this issue · 4 comments
Greetings! :)
Thanks to the emerging support for OCI images at the operating system level, there's a growing number of users who layer images on top of each other.
This presents new issues with the way rpm-ostree functions, since this usage wasn't anticipated when rpm-ostree was designed. Back then, all custom repos were added by the user. Nowadays, the repos can be provided by the operating system image instead.
But since the repos are currently stored under the regular /etc folder, it's possible for users to "mess up their system" by simply tweaking anything inside a /etc/yum.repos.d/*.repo file. That change then ensures that they're never going to receive any updates for that repo file anymore.
It has implications for their ability to layer more packages (via rpm-ostree install). For example, let's say that an OCI image contains RPM Fusion in /etc/yum.repos.d/rpmfusion-free.repo, and the user is on Fedora 38. If they then tweak or touch that file for any reason, their RPM Fusion repo file will forever stay at version 38 even when they upgrade to higher Fedora versions.
It probably also breaks operating system updates. If they have layered a few packages from one of the bundled *.repo files, and they then upgrade to a newer Fedora version, then rpm-ostree will fail to find updated versions of their layered packages when installing the new OS version (if the repo file was marked as "edited" and therefore didn't get upgraded).
This issue therefore conflicts with the ability to have hassle-free, unbreakable systems.
As far as I can see, all paths are hard-coded to use /etc, but it would be solved if rpm-ostree could instead read from /usr/lib/yum.repos.d too (and simply giving priority to the regular /etc in case of repo filename conflicts between the two locations). :)
We want /usr/lib/yum.repos.d here really. /usr/etc in the ostree model is just a source of defaults, not something other code should read. Also, while such a feature would align well with (rpm-)ostree indeed as you've pointed out, this isn't specific to it, and I think as such this makes the most sense done in libdnf so that it would also work for dnf.
@cgwalters Thank you for the clarifications. That makes perfect sense.
I noticed that you're on the libdnf team. As such, do you want me to create a ticket there, or is this one sufficient? I could make one as a simple link to this description. I'll also edit the initial post above to mention the new proposed path.
I am guessing that it will also require some changes in rpm-ostree though, since the hard-coded path is in a few places here too.
This is my "average user" anecdotal experience how this bug affected me.
I installed gnome-vrr
https://copr.fedorainfracloud.org/coprs/kylegospo/gnome-vrr/
which was at 43.1 version. Remember this.
I downloaded the repo from the website manually with browser & copied it to /etc/yum.repos.d/ file location.
When downloaded from the website, repo had this filename: "kylegospo-gnome-vrr-fedora-37.repo". Remember this sentence.
I updated my system regurarly with terminals "rpm-ostree upgrade" command & I felt like everything was nice & smooth.
One day, when thinking, I remembered that all my repos had f37 in names. I thought that it may cause issues in case of upgrading to Fedora 38. So I renamed it to just "kylegospo-gnome-vrr.repo".
I upgraded my system for some time succesufully, but one day, I remembered how I never saw the gnome-vrr update & I started to wonder if everything was okay.
I went to the copr repo website & I found out that the latest gnome-vrr version was 43.2 while my version was still at 43.1.
I redid everything from the scratch, includding reverting & installing & I never got the issue ever since.
Just to add a thought: There's a scenario where this would be more likely to affect people: Anyone who has manually downloaded a .repo file on Silverblue knows that they'll sometimes have to edit the repos to set the new Fedora version's URLs before upgrading Silverblue. This could lead certain users to manually going through all of their repos and editing them "out of old habit". That would then mark those files as "manually edited" and prevent further repo file updates from the OS's OCI image.
And since the /etc files are edited, they also won't be properly auto-deleted anymore when they're intended to be removed from the system, by the OCI creator. This is especially problematic if the OS updates are meant to rename a repo file. In that case, the user will have both the old (edited) and new (OS bundled) .repo files activated, with two different names.
While the amount of users who mess around with these files is certain to be low, it would be a great improvement for system robustness if the additional, immutable repo config location can be added. :)