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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
