I’m using Fedora Kinoite since a while, and I really like it. There’s just one thing I don’t understand, and have a hard time finding an answer to.

What happens in my home directory if I rebase to Silverblue? Like, Gnome and its apps comes with a lot of config files. If I then roll back to Kinoite, will all those files and folders still be there? How can I prevent this cluttering of files and folders that I don’t want to keep? I guess the easy answer would be to create a new user and then delete that home directory after rolling back, but I’m wondering if something else will happen. Thank you!

  • CertifiedDook@lemmy.world
    link
    fedilink
    arrow-up
    13
    ·
    7 months ago

    That’s a good question. Kinoite does not version some directories, such as your home directory or /etc. Rebasing and then reverting the rebase will create some clutter. What I’d suggest is to use some utility to version your files, perform a backup before doing the rebase or snapshot your home directory using the builtin snapshot functionality of btrfs. Maybe something like restic would work for this case.

    • biribiri11@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      7 months ago

      To add onto this, if you really wanted to rebase and don’t want config file clashes, you can use ostree config-diff after rebasing to show what config files changed. You can also simply remove all the files in /etc, and on the next boot, ostree will re-populate it with the contents of /usr/etc in a three way merge. Just be sure to copy, at bare minimum, /etc/shadow, /etc/passwd, and /etc/fstab otherwise it’ll be very awkward when you try to boot again and your boot process fails because it doesn’t automatically mount your disks and you can’t login because you have no users. It’s kinda cool tho, that, at least for this very specific issue, those 3 files might not be needed if/when systemd-homed’s JSON User Records and Discoverable Partitions see wider adoption.

      (Note: this is dumb and error prone, and you should absolutely do what the other commenter said)

    • waitmarks@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      just a small correction, /etc does get snapshotted when upgrades happen and will roll back along with everything else. you are correct though that home does not get snapshotted and is fully mutable.

  • Vincent@feddit.nl
    link
    fedilink
    arrow-up
    6
    ·
    edit-2
    7 months ago

    This is the main reason I don’t generally rebase on anything except versions I intend to stay on if things work well. Yes, you’ll keep your files and folders, but the updated software will write to them, and those will stay there too.

    For example, new versions of Firefox might make modifications to your profile directory that might not work in earlier versions of Firefox. So if your rebase gives you a newer version, than reverting will break your Firefox profile.

    (Now with Firefox specifically this isn’t usually a problem, since even older OS releases will have the latest Firefox versions, and Firefox itself is pretty stable too, but the concept could also apply to other software.)

    • thayer@lemmy.ca
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 months ago

      Leveraging flatpaks, as per the recommended workflow, largely negates these issues as well. Userspace apps shouldn’t be impacted by the host OS changes in such cases.

      • Vincent@feddit.nl
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        It does, for the apps that are Flatpaks. But e.g. most of GNOME, and Firefox, are part of the immutable image at least for Fedora Silverblue.

        • thayer@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 months ago

          I admit I typically hide the RPM Firefox and stick to the flatpak version. Aside from Nautilus though, in my experience most of the core GNOME user apps are provided via flatpak under Silverblue, including things like GNOME Calendar, Text Editor, Contacts, Totem, Evince, EoG, etc.

          • Vincent@feddit.nl
            link
            fedilink
            arrow-up
            2
            ·
            7 months ago

            True; I’m mostly thinking about foundational pieces like GNOME Shell and settings, which could still wreak quite a bit of havoc. I don’t actually know how often those introduce such breaking changes, but I’d rather not risk it.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      Very important point.

      This is also why you should not use toolbox but distrobox, and use a different home directory than your own.

      Otherwise different OS versions etc. will give you dotfile conflicts like hell.

  • Pantherina@feddit.de
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    Home is mutable, and the mess that at least KDE does (not sure about GNOME) make removing its traces really hard.

    I should write a script to remove all traces of KDE on a system, or to back everything up and import it etc.

    Find me on Github if you want to help collect all the directories and files.

    Its a total mess and can cause a ton of issues. The easy way to test DEs is to use a separate user account per Desktop. Lol.

    • KlavKalashj@lemmy.worldOP
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      That is what I feared. Using another user is a solution but it feels inelegant. I wish there were some middle ground, like being able to pin the home folder or something. I’ll take a look at your github!

      • Pantherina@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        7 months ago

        I had another idea, collect the locations (you can create a PR just listing them commented out) and then move the files to ~/.config/kde and hardlink (ln -S) them to the used locations.

        Iconsets and maybe themes are also problematic and not directly KDE related, but these are the ones that cause compatibility issues.

        I would also like to separate it between core Plasma (what Kinoite has installed) and the full KDE suite, and I would focus on core Plasma first.

  • MajinBlayze@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    7 months ago

    I installed kinoite on my laptop. Rebased to silverblue for a while to try out gnome, rebased to kinoite rawhide to check out kde plasma 6, then back to kinoite 39. I think a few minor settings had to be redone, but no real issues.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      7 months ago

      Especially KDE and GNOME somehow mess up each others icons, so no this is not true.

      These issues have to be fixed by the projects, putting their dotfiles in ~/.config/kde or ~/.config/gnome respecively.

      • MajinBlayze@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        7 months ago

        I didn’t have this experience? TIL

        To be fair, all of that was in the course of less than a week, and I neither heavily use nor customize my personal laptop, so it’s likely that if there are issues, I didn’t encounter them.

        Even so, I was quite impressed with how simple and seamless it was for me.

  • MalReynolds@slrpnk.net
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    7
    ·
    7 months ago

    Did it, to bazzite, pretty painless. Yup, your config is the same. Immutable is indeed immutable.

      • MalReynolds@slrpnk.net
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Ah, yes, bad phrasing on my part which assumed knowledge. The OS is immutable, but those three are mutable. I should also have pointed out it’s prudent to spin up a new user if switching between Gnome and KDE due to dot file overlap, I’d be unsurprised if that applies to other DEs/WMs…