> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall? No > How will it roll back the app launcher icon

> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall? No > How will it roll back the app launcher icons, which is shared by all DEs? Each DE inserts stuff like system monitor, settings etc. Application resources like .desktop files and icons are aggregated into _profiles_ via symlinking from the packages, and each state your profile has ever been in is stored as a _generation_. For example: tree ~/.guix-profile/share/applications/ /home/pxc/.guix-profile/share/applications/ ├── icecat.desktop -> /gnu/store/mq4f1615dri8v7b98m1bdmp9gzymb2n9-xdg-desktop-database/share/applications/icecat.desktop ├── mimeinfo.cache -> /gnu/store/mq4f1615dri8v7b98m1bdmp9gzymb2n9-xdg-desktop-database/share/applications/mimeinfo.cache ├── xonotic.desktop -> /gnu/store/mq4f1615dri8v7b98m1bdmp9gzymb2n9-xdg-desktop-database/share/applications/xonotic.desktop ├── xonotic-glx.desktop -> /gnu/store/mq4f1615dri8v7b98m1bdmp9gzymb2n9-xdg-desktop-database/share/applications/xonotic-glx.desktop └── xonotic-sdl.desktop -> /gnu/store/mq4f1615dri8v7b98m1bdmp9gzymb2n9-xdg-desktop-database/share/applications/xonotic-sdl.desktop ls -lh /var/guix/profiles/per-user/pxc/guix-profile* lrwxrwxrwx 1 pxc pxc 19 May 15 22:40 /var/guix/profiles/per-user/pxc/guix-profile -> guix-profile-3-link lrwxrwxrwx 1 pxc pxc 51 Apr 26 21:37 /var/guix/profiles/per-user/pxc/guix-profile-1-link -> /gnu/store/gqgfiz81llym5pck6glaihyad1kaa7gz-profile lrwxrwxrwx 1 pxc pxc 51 Apr 27 13:09 /var/guix/profiles/per-user/pxc/guix-profile-2-link -> /gnu/store/plzgyav34prz168dggbjs3g24yc74d46-profile lrwxrwxrwx 1 pxc pxc 51 May 15 22:40 /var/guix/profiles/per-user/pxc/guix-profile-3-link -> /gnu/store/j78z6waqrq1vzwgv428bbhvjldhdkbsi-profile -rw-rw-r-- 1 pxc pxc 0 May 15 22:39 /var/guix/profiles/per-user/pxc/guix-profile.lock Guix rolls back application icons the same way it rolls back the applications: your Guix profile's symlink gets rolled back to an earlier generation. When a desktop environment picks up on that change will depend on how it watches its XDG paths and updates its caches. Afaik Guix (and Nix) don't currently do anything to manage the state of those caches, but logging out and logging back in will suffice. On Plasma, I sometimes run `kbuildsycoca5 --noincremental` to manually refresh my icon and .desktop definition caches. > Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro? WebExtensions and native messaging hosts are packaged in Guix. I wouldn't install them with Guix for use by your base system's browser package, even though that will most likely work. Instead, I'd tell Guix to install both, or to install a browser configured to use whatever extensions. If you install a browser via Guix, it will not see the extensions that your base system has installed into /usr/share or wherever. I'm not sure if Guix currently has a package for Plasma's browser integration, but Nix does. In that case, by default it happens to be off, but it is easy to toggle. Whether that integration is enabled is considered a property of your Firefox package, but switching to a new Firefox package where you've changed that option (and perhaps others) doesn't require rebuilding Firefox. So in a word, yes, I think it does solve that problem. > Firefox by itself can disable/remove that extension too. This happens at the level of configuration files in your home directory, stuff under `~/.mozilla/firefox/...`. Managing such files is not part of Guix package installation or removal, so Guix won't affect that functionality one way or the other. (There are optional Guix-based tools that you can use to manage such files if you choose, though.) > If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python? It's not clear to me what it means for an OS to need Python in this context. If you're using Guix on a ‘foreign distro’, Python installations managed by Guix will ignore all of the base system's Python packages, and the base distro will pull in its own copies of Python and Python libraries to satisfy the dependencies of its packages according to its own package management system. Guix makes no difference here. If you're asking about GuixSD, the Guix-based operating system, the OS itself doesn't need you to supply anything external to it— there is no installable package or service in GuixSD that depends on Python which will look for and pick up whatever `python` executable it finds on the PATH. Packages and services that need Python come bundled with their own Python environments, which are fixed as part of the definition of the package or service. If you're talking about GuixSD and by ‘the OS needs Python’, you mean ‘I want a Python installation and environment to be available to all users system-wide so that anyone can invoke it at the command line with `python` and write scripts that use it when invoked with a `#!/usr/bin/env python` shebang’: yes, it is easy to install a copy of Python which is newer or otherwise different from those included in the default package collection. If the most recent version of a given package included with Guix is not recent enough for you, you probably don't need to resort to adding an entire third-party package repository to install a more recent one on your system. However, Guix does support third-party package repositories and if one provided a version of Python that you liked, you could install it system-wide.