questions concerning basedirspec

[Simon McVittie]

On 18/01/12 18:25, chrysn wrote:
> * /var vs. /usr/{local/,}. when i access globally installed data, i have
>    to know whether they are static or variable, and according to fhs go
>    to /usr/{local/,}share/ or /var/.

(My personal opinion, others might disagree.)

I think XDG basedirs are only directly relevant for apps/services 
intended to be run by a "normal user" who has logged in in the usual 
way, via login(1) or SSH or GDM or whatever. For system services, we 
already have the FHS - I think "the system instance of mpd" (to pick an 
existing example of something that can either be a system service or a 
user service) is distinct from either root's per-user instance of mpd, 
or the mpd user's per-user instance of mpd (neither of which should 
happen, in practice).

If nothing else, much of the purpose of basedirs is to have a single set 
of environment variables you can set (in your .xsession or .bashrc or 
whatever), which affect all user applications - but system services are 
run by init, not by a user's login process, so they don't see *anyone's* 
environment variables!

In the basedir spec, the closest thing to the var/usr distinction is 
that XDG_DATA_HOME can be either dynamic or static, whereas 
XDG_DATA_DIRS is static (because you should always write into 
XDG_DATA_HOME instead).

Most users of the basedir spec are applications (e.g. Firefox) or 
services (e.g. Telepathy) that will only ever run per-user, so the 
question of what to do about a system service never arises. For things 
that can run as either a system or user service (like mpd, PulseAudio, 
dbus-daemon or your calypso), you probably want two code paths - FHS for 
a system instance, or basedir for a per-user instance. I'd suggest 
achieving this via a --system option which changes the defaults accordingly.

(For instance, the system-wide mpd on Debian has settings in its init 
script which direct it to use /etc/mpd.conf and have system-like 
behaviour, while PulseAudio has pulseaudio --system=true and D-Bus has 
dbus-daemon --system.)

Another way you could do it would be to have your init script (or 
systemd unit or whatever) set the basedir environment variables before 
running the service, with values like:

     XDG_CONFIG_HOME=/etc
     XDG_CONFIG_DIRS=/etc
     XDG_DATA_HOME=/var/lib
     XDG_DATA_DIRS=/usr/local/share:/usr/share
     XDG_CACHE_DIR=/var/cache

which, if you're using paths like ${basedir}/myapp/ for everything, 
would result in it doing the expected system-service things.

 > * concerning /etc/xdg: a typical setup of a program named calypso
 > would these days have its global config in /etc/calypso/config and
 > its user config in ~/.config/calypso/config. thus (unless
 > XDG_CONFIG_DIRS is set to /etc/xdg:/etc, which isn't the case
 > anywhere i've seen so far), the application could not use xdg
 > for config file resolution without some manual quirks or
 > migrating its config files.

There's nothing to stop you from searching historical paths or 
environment variables in addition to the basedir, to provide a migration 
path. Yes, that requires some this-app-specific code, but basedir isn't 
a difficult spec to implement - a full implementation in a high-level 
language is only a few lines.

In general I'd recommend giving the basedir spec highest priority, but 
following historical behaviour if you still don't find anything.
Telepathy used to do this, for backwards compatibility with some 
paths/variables that pre-dated our adoption of XDG basedirs - we'd 
search ${TP_SOMETHING_PATH} if there was no ${basedir}/telepathy/something.

If you do the user/system split that I recommended, I would tend to 
think that /etc/calypso/config (or even /etc/calypso/system.conf) was 
configuration for the single system-wide instance, whereas 
/etc/xdg/calypso/config contained default settings for per-user 
instances whose user does not have a ~/.calypso/config?

     S