I’m trying to update my Kinoite machine (rpm-ostree upgrade) and I get this error:
error: Could not depsolve transaction; 1 problem detected:
Problem: conflicting requests
- package steam-1.0.0.85-2.fc43.i686 from rpmfusion-nonfree-updates requires gtk2(x86-32), but none of the providers can be installed
- package steam-1.0.0.85-1.fc43.i686 from rpmfusion-nonfree requires gtk2(x86-32), but none of the providers can be installed
- package gtk2-2.24.33-23.fc43.i686 from fedora requires libpango-1.0.so.0, but none of the providers can be installed
- package gtk2-2.24.33-23.fc43.i686 from fedora requires libpangocairo-1.0.so.0, but none of the providers can be installed
- package gtk2-2.24.33-23.fc43.i686 from fedora requires libpangoft2-1.0.so.0, but none of the providers can be installed
- package pango-1.57.0-1.fc43.i686 from fedora requires harfbuzz(x86-32) >= 8.4.0, but none of the providers can be installed
- package pango-1.57.0-1.fc43.i686 from fedora requires libharfbuzz.so.0, but none of the providers can be installed
- harfbuzz-11.5.1-1.fc43.i686 from fedora does not belong to a distupgrade repository
- cannot install both harfbuzz-11.5.1-1.fc43.x86_64 from fedora and harfbuzz-11.5.1-2.fc43.x86_64 from @System
From looking at various forum threads I understand that the general solution to this problem is to wait a couple of days for the regular RPMs and OSTree repo to catch up.
But I’m trying to understand exactly what happened here so I can learn more about the system. More concretely, I’m trying understand why rpm-ostree attempted to install two versions for harfbuzz and why is it using the wrong architecture.
I tried to follow the dependency chain from the error message:
steam-1.0.0.85-2 requires gtk2(x86-32). OK, I see that rpm -q --whatprovides 'gtk2(x86-32)' gives gtk2-2.24.33-23.fc43.i686, all good.
Next, we see that gtk2 depends on a few libpango SOs. I used --whatprovides again and see that they are all provided by pango-1.57.0-1.fc43.i686, all good.
Next, we see that pango depends on a generic version of harfbuzz (harfbuzz(x86-32) >= 8.4.0), which is OK because we have harfbuzz-11.5.1-1.fc43.i686, much newer.
Now comes the puzzling part. We have two lines:
“harfbuzz-11.5.1-1.fc43.i686 from fedora does not belong to a distupgrade repository”.
First, I’m not sure what it means, we’re not trying to upgrade any major versions of Fedora here.
Second, where did the 11.5.1.1-1 version come from? Nothing in the dependency chain required it specifically and the latest version we have in the new OSTree commit is 11.5.1.1-2. (I checked with rpm-ostree db list fedora:fedora/43/x86_64/kinoite | grep harf). In addition I see that 11.5.1.1-2 is available in the regular RPM repos: Making sure you're not a bot!
“cannot install both harfbuzz-11.5.1-1.fc43.x86_64 from fedora and harfbuzz-11.5.1-2.fc43.x86_64 from @System”. But why would it try that???
First, we’re talking about i686 version that is needed for steam. Why is it trying to install x86_64 version?
Second, here as well, where did the 11.5.1.1-1 version come from?
Note that before the upgrade I have two version of harfbuzz peacefully coexisting:
$ # On the sytem before the upgrade:
$ rpm -q harfbuzz
harfbuzz-11.5.1-1.fc43.x86_64
harfbuzz-11.5.1-1.fc43.i686
Also note that I ran rpm-ostree refresh-md before all this and I have only default repos + rpmfusion.
I would really appreciate an explanation or pointers to documentation that I might have missed
I suppose that the i686 packages are required by steam, or maybe wine. Dependency issues had been reported in the past too, because out-of-sync pushing of updates between Fedora and RPM-Fusion. The issues were usually going away in a few days. You might experience a similar issue.
I also notice you have quite a few packages removed from the base layer. Because of the nature of RPM-OStree overrides, it is recommended that such actions should only be short-term solutions. From the man page:
Such modifications should be done with care and are normally not intended to be long-lasting.
Changes in package runtime requirements can cause such dependency conflicts as you are experiencing too.
If those base packages are removed in order to have proper multimedia codecs, note that in my experience there is no need to remove base packages. All I needed to do in the past was to rpm-ostree install libavcodec-freeworld. Now I don’t even do that, since I am using Flatpaks from Flathub, which bring their own multimedia condecs runtime extensions.
Finally, a bit off-topic, but you can run the below command in order to turn the RPM-Fusion local packages into layered packages, which will let you do upgrades to future major versions:
Fedora is just delivering pure x86_64 arch which is 64 bit. The rest is just for older 32 bit apps which are still around. When you update the x86_64 architecture and the i686 architecture software needs a different version it gets this conflicts (very simple explained).
Yes, that’s indeed that happened eventually. I still couldn’t understand the original conflict, since steam didn’t depend on an exact version of any external package.
Yes, I removed them because that’s what RPM Fusion documentation says. Since I’m not fluent in Linux codec architecture I don’t know what are the implication of removing vs keeping the base codec and I didn’t want to diverge from the “common path”. I’ll try your approach see if Firefox can still play videos (basically the only non-Flatpak multimedia app I have).
Will try, thanks!
The part that’s confusing to me is why “the i686 architecture software needs a different version” since I couldn’t find any exact version requirement in the dependency tree of steam.
I don’t know why RPM-Fusion recommends removing all those base packages, more so because the instructions start with the install subcommand, so it’s expected that the override remove one is not needed for the former to succeed. They certainly have their reason to recommend it though.
As mentioned previously, I didn’t need to remove any bases packages in order for Firefox from the base image to work with multimedia codecs, but rather only installed multimedia packages from RPM-Fusion.
FWIW, I don’t rely on Firefox from the base image any more, but I’m using the Flatpak version from Flathub, and I have hidden the default Firefox RPM app according to this instruction.
As I understood with the copr repo, they are not always in sync with fedora, alias are ahead because they make their work sometimes weekends when they have time. Might be that with the rpm-fusion is the same?
Tell me, can you not just take the older deployment again and wait till the mess is solved? With the atomic desktop this should be easy, right?
In this line, notice that the newer package is from @system (that means it’s what’s already installed at the beginning of the rpm transaction[1]), whereas the older one is from fedora (i.e. rpm-ostree wants to pull it from a repo).
Is the following a possible scenario that could cause this?
The Kinoite base image downloaded for the update included the newly released harfbuzz-11.5.1-2.fc43.x86_64
Then, on top of that Kinoite base image, your rpm-ostree command needs to apply layering. That requires it to pull packages from a repo mirror to your local machine. Those packages include the i686 variant of harfbuzz. (The standard Kinoite image doesn’t need to include that i686 variant, but your layered deployment does, because steam depends on it.)
Assume that selected mirror happens to have harfbuzz-11.5.1-1 but not harfbuzz-11.5.1-2 (because that’s a recently pushed update, and there’s some propagation time).
So the layering process tries to get harfbuzz-11.5.1-1.fc43.i686, which is the latest i686 version of that package it can see.
I assume (without a lot of rpm-ostree knowledge) that rpm-ostree doesn’t automatically perform this downgrade, as it would only be possible by creating a new override for harfbuzz.
But this may well be wrong, I don’t know rpm-ostree enough to be confident.
not necessarily at the beginning of the whole ‘update’ operation, which involves an image pull before the rpm transaction for the layering ↩︎
Correct, the override remove command is coupled with an install command of ffmpeg. I’ve overlooked that, thanks for pointing it out. And indeed, ffmpeg conflicts with ffmpeg-free, hence the override remove command.
Nevertheless, the general advice that removing base packages shouldn’t be long-lasting still stands. For those not needing the ffmpeg package, there are overlay commands which don’t require removing base packages, e.g.:
That was my first assumption, but I immediately opened a new container and tried to dnf install harfbuzz.i686. This installed 11.5.1-2 version so I assumed the Fedora mirror for my location is up-to-date. I also did rpm-ostree refresh-md on the host to make sure I’m using fresh data.
Maybe for some reason rpm-ostree picked a different mirror which didn’t have the update, I didn’t check. But that would be a plausible explanation.
