linux-traipu team mailing list archive

[Mike Carifio <1887804@xxxxxxxxxxxxxxxxxx>]

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 UBUNTU -
AL - BR, which is subscribed to Chromium Browser.
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