Add XDG_STATE_HOME

[ayekat]

The XDG base directory specification defines XDG_DATA_HOME as a place where "user specific data files should be stored". This description is obviously a bit vague, and it fails to properly distinguish between static/immutable data (equivalent of /usr/share or /usr/lib) and mutable data for state information (equivalent of /var/lib), and has now led to this issue.

I have observed that the majority of application appear to treat it as the latter, and store mostly state/mutable data into XDG_DATA_HOME. There are a few exceptions to this, though (e.g. applications or icons, whose FHS equivalent would probably be in /usr/share), so really it's a mix of two different things.

Since I'm already in the business of extending the severely lacking XDG basedir spec with custom variables (think XDG_LOG_HOME and XDG_LIB_HOME), the proposal is thus now to add another new variable intended to properly split up these two things. The two options are:

XDG_???_HOME for immutable/static data, XDG_DATA_HOME for mutable/state data

This is the way I've treated it so far (it points to ~/.local/var/lib), and it appears to be the way most applications use it for (which is understandable, because static data is rarely generated at runtime, and is usually already present system-wide, i.e. /usr/share and /usr/lib).

If we keep it this way, we'd need to introduce a new variable name (can't think of any right now) and have it point to ~/.local/share.

XDG_DATA_HOME for immutable/static data, XDG_STATE_HOME for mutable/state data

This would be the opposite approach, and we'd need to introduce a new variable for the state information. This seems more consistent for various reasons:

• XDG_DATA_DIRS is the equivalent for all static data directories (defaulting to /usr/local/share:/usr/share), so reusing DATA as the static equivalent under the users' home directories seems sensible.
• There have been multiple proposals and custom extensions in the past for mutable/state data, usually labeled XDG_STATE_HOME, so we'd already have a commonly accepted name.
• I expect it to be easier to move applications to storing their data (mutable) in a different location than to move applications to expect existing data (immutable) in a different location. Putting the base data directory in ~/.local/share and then telling applications to store their state in ~/.local/var/lib seems thus a viable strategy.

---

Yes, you may notice that I'm in favour for the second option :-)

Links

• https://wiki.debian.org/XDGBaseDirectorySpecification#Proposal:_STATE_directory
• https://lists.freedesktop.org/pipermail/xdg/2009-February/010191.html
• https://lists.freedesktop.org/pipermail/xdg/2012-December/012598.html
• https://lists.freedesktop.org/archives/xdg/2016-December/013803.html
• https://github.com/ActiveState/appdirs/commit/ea0701d7550fc290384c949b4a8e492a05163bce
• … and more! (search the web for XDG_STATE_HOME)

[ayekat]

So now we've got XDG_DATA_HOME set to ~/.local/share and XDG_STATE_HOME set to ~/.local/var/lib.

In an ideal world, this should change everything without any problems, but we're unfortunately still using some applications where we have to hard-code the path (so there the application will continue to use ~/.local/var/lib), so nodes that want to clone the last few commits will need to create a symbolic link from one to the other (preferrably ~/.local/var/lib -> ~/.local/share) first, to avoid stuff breaking.

There are a couple of other "synchronisation points" that each need to be completed by all hosts before tackling the next:

• [x] Rename ~/.local/var/lib to ~/.local/share and create ~/.local/var/lib -> ~/.local/share symbolic link
• [x] Apply XDG_DATA_HOME=~/.local/share and XDG_STATE_HOME=~/.local/var/lib

• [x] Replace the symbolic link by a directory and move all application data directories in there from XDG_DATA_HOME that have hardcoded paths to ~/.local/var/lib:

  • mail
  • mpd
  • ncmpcpp

  Also create symbolic links for applications that partially use both:

  • mail (pooch vs mbsync)

• [x] Start moving stuff for other applications as well (have fun…!)

  • [x] cargo
  • [x] checkupdates
  • [x] darktable
  • [x] gimp
  • [x] gpg
  • [x] less
  • [x] mariadb/mysql
  • [x] pass
  • [x] pidgin
  • [x] qutebrowser (see also #29)
  • [x] sbt
  • [x] task
  • [x] vim

  Mostly this can each be done in 3 steps:

  1. (from within $XDG_DATA_HOME): mv {app} ../var/lib/ && ln -s ../var/lib/{app}
  2. Update the application/configuration in question
  3. rm $XDG_DATA_HOME/{app}

The nodes that will synchronise for this are: chirschi, kiwi, heidubeeri, brombeeri, fyge, penrose and rainbowdash.

[ayekat]

There's still some applications that don't allow configuring their data location, and hardcode it to XDG_DATA_HOME, so they will remain in ~/.local/share for now. But fundamentally, switching to this new variable appears to have worked.

Closing as fixed.

[ayekat]

Ah yes, remark: Applications supporting XDG_STATE_HOME default to ~/.var/state if it's unset. This follows the proposal of Allison Lortie made here (EDIT: actually, it appears ~/.var/state specifically is never mentioned there, only ~/.var—my bad).

This differs from the other (more popular) proposal that uses ~/.local/state as a default, because I consider ~/.local to be the equivalent of /usr or /usr/local (thus potentially immutable), whereas state, logs and cache are all mutable, hence in a different tree (/var in the FHS).

Ideally, we could one day also have XDG_CACHE_HOME use ~/.var/cache as default (and XDG_CONFIG_HOME use ~/.local/config), but I don't believe that'll ever happen.

Buuuuuut anyway, we've got XDG_STATE_HOME!

[ayekat]

I just discovered that the latest XDG base directory specification has added XDG_STATE_HOME. :tada:

They default to ~/.local/state. As mentioned above, that is a bit unfortunate, but that's just a minor complaint.

Now I need to update all my applications to set the correct default value…

[roosemberth]

 🎉

On 26 October 2021 23:41:35 CEST, Tinu Weber @.***> wrote:

I just discovered that the latest XDG base directory specification has added XDG_STATE_HOME. :tada:

They default to ~/.local/state. As mentioned above, that is a bit unfortunate, but that's just a minor complaint.

Now I need to update all my applications to set the correct default value…

-- > You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub:

https://github.com/ayekat/dotfiles/issues/30#issuecomment-952349839 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ayekat]

Updated in be2a6135b4f149af3afa8b50ec3ad269c4dabd79.

Also updated some other projects where I knew off the top of my head that they were using XDG_STATE_HOME (totp, pacman-hacks, …). There may be other scripts floating around that still need an update, but that's not something to be tracked in this repo here, so…

Closing as fixed (again).