Skip to main content
Topic: How strictly should the XDG Base Directory spec be adhered to? (Read 1270 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How strictly should the XDG Base Directory spec be adhered to?

I've been trying to do a bit of "spring cleaning" on my PC by getting rid of things like unused dotfiles and packages, and I've been wondering as of late whether the XDG dir spec is worth following considering its aims to unclutter the home directory.

How worthwhile is it to adhere to their spec — in spite of everything else that fd.o likes to throw at people like systemdicks — and what solutions does Artix provide for users who would like to stick with it to that extent?

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #1
I've removed directories such as Documents and Videos for a good while now, almost nothing complains, not even Wine, and xdg calls are nice enough to not recreate them unless a client program explicitly does so (very rare).
The only problems are when a program wants to write to those paths (also rare ish), some are smart enough to write directly in the root of the home directory (if you're not careful and you use an exotic program, watch out that it doesn't litter your home directory this way), others will silently throw an error.
The dotfiles are all safe to remove except the one in Desktop (if you use a form of DM session that is, otherwise remove that too)

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #2
I've removed directories such as Documents and Videos for a good while now, almost nothing complains, not even Wine, and xdg calls are nice enough to not recreate them unless a client program explicitly does so (very rare).
Those I don't have that much issue with since I would try to make use of those when I was still on Windows a good few years ago. What I was referring to more was the adherence to things like XDG_CONFIG_HOME and trying to make sure as much of the software installed makes use of it instead of its own dotted folder under HOME.

The Arch wiki seems to cover a pretty exhaustive list of cases, for example, which I've been taking a look at for my own reference just now.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #3
Okay, now I get it. I never thought of such a use case before, i only knew of moving the entire /home to another partition.

The idea of having XDG_CACHE_HOME write to a ramdisk is certainly very interesting, especially when you wipe that directory often.

Otherwise the rest like .config for me don't make sense, probably for testing maybe.

I'll try to test it quickly, one sec

LE: Oh my, it does work, as a test i pointed XDG_CACHE_HOME to /tmp and nothing gets written in ~/.cache anymore
I'll actually do this from now on, just gotta automate the creation of a separate directory in /tmp before the session loads to avoid conflicts
And probably point it to another path when making big 10GB compiles :D

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #4
LE: Oh my, it does work, as a test i pointed XDG_CACHE_HOME to /tmp and nothing gets written in ~/.cache anymore
I'll actually do this from now on, just gotta automate the creation of a separate directory in /tmp before the session loads to avoid conflicts
And probably point it to another path when making big 10GB compiles :D
Wait, how'd you manage that?! Are you using something akin to ~/.bashrc for that? I can't seem to replicate that for every program right now.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #5
LQXt Session Settings in my case, you can also use .Xprofile etc etc.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #6
Interesting thread. (to me  :) )

I like to keep the data away from the dotfiles. For ease of backups.

My setup
I have a directory ~/Files. It's a separate partition, it is mounted there in fstab.
Directories such as Desktop, Downloads, Pictures etc etc are all under ~/Files and setup in KDE as such.

I make a daily incremental backup of ~/ with rsnapshot-timestamp. 7 days / 4 weeks /forever months
I keep important stuff in various ~/Files/Nextcloud/* directories so that gets backed up on my nextcloud server.

I further complicate things by having a folder ~/Files/.dotfiles and big stuff I'm not so fussed about losing, from ~/.local/share , is actually stored there then linked back to ~/.local/share (lutris, wine prefixes, emulator stuff etc).

~/.cache is it's own ram tmpfs
Code: [Select]
tmpfs                                           /home/user/.cache 	tmpfs   		noatime,nodev,nosuid,size=28G

 

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #7
@gripped
Hmm so force mounting the path in fstab does the same thing, interesting.
Does the tmpfs volume scale itself dynamically so I can size it above physical ram (and e.g. go into swap in case it ever gets big)? Or you have above 28gb ram? Cause I would like to not worry about the cache dir ever to cause a OOM and get something killed/be deleted unexpectedly.

PS my backup scheme is primitive, I do a semi manual backup of the home dir with some exclusions in tar, and put that on hard drive every week or so :)

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #8
use xdg-ninja to find packages that are supported.

If you care enough, you can always keep the output of
Code: [Select]
~$ ls -al | wc -l
to less than 30

i recommend keep your home close to this 
Code: [Select]
.cache
.config
.local
.ssh
Desktop
Documents
Downloads
Music
Pictures
Public
Templates
Videos
mnt
.xprofile
.zprofile

i gave up on .git .java .librewolf .gitmodules .gitignore .steam .steampath .steampid

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #9
i gave up on .git .java .librewolf .gitmodules .gitignore .steam .steampath .steampid
Any recommendation for .dbus, then? I don't quite trust at the moment that none of my software actually uses D-Bus and Arch's recommendation for it is something that basically requires soystemd for its service, so I wonder if there's some equivalent to it that would be usable on Artix.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #10
@gripped
Hmm so force mounting the path in fstab does the same thing, interesting.
Does the tmpfs volume scale itself dynamically so I can size it above physical ram (and e.g. go into swap in case it ever gets big)? Or you have above 28gb ram? Cause I would like to not worry about the cache dir ever to cause a OOM and get something killed/be deleted unexpectedly.
Yes tmpfs scales itself and will use swap if needed, though of course we don't want that. I used to have no size set for .cache but yay compiles in there and something was running out of space and failing with the default 16G.
It only uses what it needs to
Code: [Select]
~/Files                                                                                                  10:15:55
❯ df -h |grep tmpfs
tmpfs            28G  353M   28G   2% /home/user/.cache
tmpfs            16G  5.6M   16G   1% /tmp
tmpfs           3.2G   16K  3.2G   1% /run/user/1000
Quote
PS my backup scheme is primitive, I do a semi manual backup of the home dir with some exclusions in tar, and put that on hard drive every week or so :)
Check this out https://github.com/kmccormick/rsnapshot-timestamp . It's a wrapper around, and improves upon greatly, https://rsnapshot.org/ , itself a wrapper around rsync !
It's not been updated in years but it still works very well.
Every night cron jobs do incremental backups of my home dir, my local mini-pc server (nextcloud, email server, websites), and four remote vps's (some mine, some other peoples). And I don't have to lift a finger :) Any thing goes wrong and i can revert to a chosen (available) date.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #11
I got it now, thank you.

I'll certainly try that utility, maybe with this occasion i won't longer find rsync to be as weird as i thought it is :D

used to have a thin client myself, didn't use it for much back in the day so when it's psu broke in a power surge i just gutted it out for parts, I'd get one now to use as a router, (openwrt is in kind of a bad state right now due to their aggressive policy of updating kernel, and also kinda rushing nft), wireguard offload, server indeed and a few other things.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #12
Any recommendation for .dbus, then? I don't quite trust at the moment that none of my software actually uses D-Bus and Arch's recommendation for it is something that basically requires soystemd for its service, so I wonder if there's some equivalent to it that would be usable on Artix.
Turns out there is a dbus-broker package also maintained on Artix. Now the question is what the setup for it as a drop-in replacement for regular dbus init looks like, since the documentation is written exclusively with systemd in mind and there don't seem to be any packages for an alternate init script (in my case, runit).

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #13
The general separation of things into the .cache/.config/etc. directories I find helpful and useful. Cluttering the home directory with junk is not something I'm fond of. Fortunately, most programs nowadays respect this. There's just a few notable outliers left (dbus, mozilla, etc.)

Turns out there is a dbus-broker package also maintained on Artix. Now the question is what the setup for it as a drop-in replacement for regular dbus init looks like, since the documentation is written exclusively with systemd in mind and there don't seem to be any packages for an alternate init script (in my case, runit).
Unfortunately, the init/launcher for dbus-broker is written specifically for systemd. There's no way for us to write user scripts for it until someone adds a non-systemd dependent launcher for dbus-broker.

Re: How strictly should the XDG Base Directory spec be adhered to?

Reply #14
For those who might still be curious, someone has recently released a utility for Steam that allows it to adhere to the XDG spec, eliminating the need for the .steam* files within the HOME directory.