I’m trying out immutable Fedora for the first time. I installed Kinoite recently. I normally use XFCE, so I had to install a few additional applications to get what I’m used to. So I installed evince, it pulled in quite a few TeXLive packages, I didn’t bother at the moment. System updates were taking a lot of time, then I learned layered packages can slow down the update process. So I uninstalled evince. Normally I would do dnf history undo <txid>, however I don’t think rpm-ostree has a history command. So I simply did rpm-ostree remove evince{,-{dvi,djvu,previewer}}.
At the time I couldn’t tell, but now I notice while evince has been removed, the texlive-* packages are still hanging around, and I can’t seem to uninstall them.
$ rpm -qa texlive\* | wc -l
70
$ sudo rpm-ostree uninstall -n $(rpm -qa texlive\* --queryformat='%{name} ')
error: Package/capability 'texlive-base' is not currently requested
$ sudo rpm-ostree override remove -n $(rpm -qa texlive\* --queryformat='%{name} ')
error: Package "texlive-base" not found
$ sudo rpm-ostree remove -n $(rpm -qa texlive\* --queryformat='%{name} ')
error: Package/capability 'texlive-base' is not currently requested
$ rpm -q texlive-base
texlive-base-20260301-111.fc44.x86_64
Can someone help me understand what’s going on? My usual Fedora debugging intuition seems to not apply on immutable Fedora.
Dependent packages should be removed when uninstalling the layered package, unless specifically installed (layered). What is the output of rpm-ostree status?
Thanks! That worked, didn’t realise that package had a TL dependency!
I’m finding immutable Fedora quite difficult to maintain and remain useful. I do a lot of different kinds of tasks on my computer, the base set of packages is quite inadequate for me. If my choice is between layer lots of packages and expect slow updates and/or debug dependency issues (like this one), or use containers for everything, it becomes quite unusable for me. I guess I’ll give it a few more weeks before giving up.
On the upside, lack of an XFCE image led me to KDE, and I’m liking it a lot so far. So even if I switch back to regular Fedora, I might keep using KDE
I find atomic desktops a great concept. There might be use cases though, where traditional desktops might be more suitable. You might not need to go that route though, and take advantage of the reliability and rollback options that atomic desktops provide.
I’m on Silverblue, and have switched a couple of releases ago from manual CLI updates back to the (default) automatic updates via GNOME Software, and now I don’t even notice when updates take place and how long they take. I just reboot at least once a week in order to be on the newest deployment.
I usually combine installing packages as follows:
layer packages for CLI apps or packages that need tighter integration with the system
use containers for testing purposes only, or when it’s not important to be on the latest version of some CLI app
all the other GUI apps as Flatpaks.
I noticed that you install GUI apps (e.g. Evince, VLC) on top of the base install as layered packages. Going with some of these as Flatpaks would ease the system updates. And if you go with multimedia apps from Flathub, you don’t even need to layer multimedia codecs and/or remove base packages.
Sometimes I need to use ffmpeg on the terminal I even have some custom scripts so that I don’t need to remember all the options But maybe this is one of the cases that fits this advice:
So rather than using a command like ffmpeg blah blah blah, it would instead be flatpak run zzz.me.ffmpeg blah blah blah.
Of course it would be annoying to type that out every time, so you could either use a shell alias or a wrapper script so that ffmpeg automatically expands to flatpak run zzz.me.ffmpeg.