I'm also confused about the expected settings of XDG_{CACHE,CONFIG,DATA}_HOME in a snap and their relationship(s) to SNAP_USER_{COMMON,DATA}. Unfortunately, chromium isn't a good example to disentagle them. Chromium (or chrome) doesn't seem to respect these values either.
Rather than state what chromium uses (and yes, it's an important example), can you @osoman state what they _should_ be? My understanding is that XDG_CACHE_HOME defaults to $HOME/.cache, XDG_CONFIG_HOME defaults to $HOME/.config and XDG_DATA_HOME defaults to $HOME/.local/share. And it would appear that well-behaved snaps do that. However, since $HOME in a snap includes it's revision (not classic containment), that means that a new revision starts those locations afresh (or the first start of the new revision copies over the previous directories). I find this behavior a little surprising, even given the "security benefit" that confinement brings. In a sense, "my" data in .local/**, .config/** and ./cache/** is really now less mine and I have to know a little bit more about the directory tree at ~mcarifio/snap/${snap}/**. And I have to pay attention to when snaps update because my configuration(s) might disappear for a misbehaving snap. It appears that the Intellij tools use classic confinement for this reason, since a new major revision will "copy over" the previous configuration when it first starts. But the app does that, not the underlying snap machinery. xdg also adds to the potential confusion with .config/user-dirs.dirs, used when XDG_* isn't exported. And unfortunately SNAP_USER_{COMMON, DATA} seem to actually be independent of XDG_* although the names suggest (to me anyways) that SNAP_USER_DATA might play a role similar to XDG_DATA_HOME. Yes, that's because I can't read :-), not because that's stated at https://snapcraft.io/docs/environment-variables. Nonetheless, the descriptions are terse. Perhaps a sentence like "not be confused with XDG_DATA_HOME" would help. I understand I'm recapitulating some of the thread above with less ummm enthusiasm and this is better discussed in the snapcraft forum. I think snaps bring a lot to the table, but when something breaks or is confusing, then I think we (the snap consumers) suddenly become very interested in the details of the packaging. And not by choice. Snaps are different. They make different assumptions (sandboxing, interfaces, multiple versions). And "personal configuration" e.g. .config/${sofware} and .local/share/${software}, is in that gray area between what's "mine" and what's "the app's". I don't have an answer to that. Just look at all the github repos for dotfiles. There are even directories of dotfiles https://github.com/webpro/awesome-dotfiles and dotfile managers like stow. But I would like to understand a little better how the "snap game" is played so I can leverage it's strengths and avoid its pitfalls. I do work to incorporate a tool into my workflow and XDG tells me to put that work in certain locations e.g. $HOME/.config/${pkg} and $HOME/.local/share/${pkg} for XDG compliant apps. HOME can't just move around willynilly for security's sake. It's nice to "know where to go" and go to one place. Snap's packages can respect XDG and still confuse because HOME is remapped on each revision and when a program is run. If you miss that detail, you're in for a world of hurt. Historically software updates didn't touch the XDG directories. Snap does. In something of an intelligent way certainly. But packaging mistakes happen all the time. Configuration files are missing. Or wrong. At some point, I know I'll be forced to repair something somewhere because I do it at least every week. Currently snaps make that a little harder, but perhaps in time will make it a lot better. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: Invalid Status in chromium-browser package in Ubuntu: Opinion Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp