Why is it that if you rebase between two atomic images that have different DEs that you get problems? I experienced this when I rebased from Kinoite to Bluefin. Some icons are messed up for me. I could understand why there would be a problem if I was using stock Fedora Atomic because updates pull only the changed packages before applying them, but since uBlue will literally swap between images I don’t see where the overlap would be that would allow for this clash.
Relatedly, is this a fixable problem? Up to now I’ve thought of the idea of image hopping as a compelling reason to try Fedora Atomic and its growing ecosystem, but if this is the experience people can expect then I shouldn’t be promoting that use case.
Fundamentally it’s ridiculous that apps stomp on each other’s dotfiles and that should be fixed, but it wasn’t a problem people cared about before. Maybe this can be a forcing function.
Yup, unfortunately, particularly when starting with Plasma (such as Kinoite) and rebasing to Gnome (Such as Bluefin) and vice-versa, they want to fight over the configuration files, if you use the same users, especially when it comes to GTK and Qt themeing.
The only practical way to stop this, is to use one user for Plasma, and one for Gnome, if you’re going to be bouncing back and forth between images, unfortunately.
Ouch, that’s not a good look. If you have to make a new user to not have the image fight over config files then I guess that works, but not having easy access to your original data doesn’t make it a smooth transition. In that case I will put my image hopping dream on hold.
I hope it can be fixed at some point because being able to do that would be appealing to lots of people.
You’re going to generally be fine, bouncing back and forth between Silverblue and Bluefin, for instance. It’s specifically Plasma and GNOME that tend to stomp all over each other.
This isn’t a new problem, by any stretch of the imagination. Grab any traditional distribution of your choice, and install it with GNOME, or KDE, and then Install the other later on, and just switch back and forth, you’ll get the same effect.
When you rebase to a new image in an rpm-ostree based system, your $HOME remains the same when you rebase.
The irony is having multiple simultaneous desktops installed used to be much smoother back in the day. Despite so many freedesktop/FHS standards, I’d say there have been some surprising regressions, sadly. During Ubuntu 6.06/Mandrake Linux days (when I first started using Linux) I’d have GNOME 2, KDE, XFCE and Enlightenment all installed on the same system and behaving well with each other, as far as I could tell. But after GTK3 and GNOME 3, GNOME and KDE became increasingly all encompassing and pursuing their own divergent paths, even though I guess XDG has attempted to unite a lot of functionality, still as far as I can read from others (I no longer desktop hop on the same machine), theming is one area that persistently remains broken. Better coordination between the GNOME and KDE folk should improve matters but easier said than done obviously.
Just curious if this would work, barely getting into Linux myself, but since you have a rebase script that checks for versions of the base and makes necessary changes such as dx on or off, couldn’t there be a check to see
if x de to x de proceed
elseif x de to y de remove x dependencies install y dependencies
or if not remove them, comment them out for use later or on a different user account?
I know this is kind of an old thread, but I was wondering if anybody familiar with the potential issues with rebasing between DEs had any recommendations for how to go about switching.
I’m fine with reinstalling instead of rebasing, but it would be great to be able to back up and then restore things like flatpak apps and data, config files, etc. in a way that doesn’t interfere with DE-specific changes. I use Pika at the moment, but I assume reinstalling and then naively restoring all of my dotfiles would bring about the same issues as rebasing would. So in that case… do I have any options besides manually setting up the system again? Thanks!!
Basically the biggest issues is going to be kde and gnome fighting over GTK theming. KDE will attempt to make gtk2.0, gtk3.0, and gtk4.0 kinda blend in with the plasma theme. It does this by directly changing the configuration files and can drop custom css files as well.
Icons are another point of contention. Fedora uses Adwaita as it’s default icon set even on kinoite. You can check this by looking in /usr/share/icons/default/index.theme. In Aurora we change that breeze, but that introduces some other problems.
Icons and the GTK issues are also happening inside your homedir which is not part of the image based updates. Again, kde wants to make gtk applications look like breeze by default and does this by changing your ~/.gtk-2.0, ~/.config/{gtk-3.0,gtk-4.0} files.
And last but not least. Image based updates don’t help for some certain edge cases. /etc/shadow is unique to your machine and every user needs an entry in that file. Swapping between gnome and kde means swapping between sddm and gdm which each have its own sysuser that won’t be defined in /etc/shadow.
