about XDG_RUNTIME_DIR

[Rainer Müller]

On 2015-11-23 17:32, René J.V. Bertin wrote:
> Freedesktop/XDG-compliant applications may use a user-specific
> location for runtime "stuff" like sockets. On Linux, this location
> usually is something like /run/user/uid. It is typically defined
> globally through the XDG_RUNTIME_DIR env. variable, with a fallback
> if that variable doesn't exist.

> How does MacPorts handle this, is there a consensus? Or are
> applications and "frameworks" left to determine their own fallback
> value because XDG_RUNTIME_DIR will typically NOT be set? The only
> beginning of an answer I have for now is the presence of a few
> ~/.cache/keyring-XXXXX directories, which may correspond to the
> similarly named keyring directories in /run/user/uid on my Linux
> rig.

Adding environment variables is complicated and involves interruption by
the required logout/reboot. If possible, we should avoid it and patch
the default settings for libraries and applications instead.

> Context: Qt5's QStandardPaths::RuntimeLocation return value. It
> defaults to ~/Library/Application Support, which I think is fine for
> "native mode" but not for an XDG-compliant mode.

For runtime files, such as sockets, this looks like an unusual location
to me. Putting them in $HOME is unnecessary, as they would not need to
be preserved (not even across reboots, and especially not in backups).

Were there any sandbox limitations involved in this choice?

> Alternatives I see:
> - $TMPDIR/runtime-username (calculated using the QSP RuntimeLocation code used on other Unix hosts)

This sounds like a sane solution to me. Runtime directory can safely be
cleared on session exit or reboot.

> - ~/.cache (to align with what Gnome *may* use).

I have not verified it, but it looks like this is the solution deployed
by GLib:

https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir

> I tend to prefer the 1st alternative to stick closest to what happens
> on Linux, but only if Qt5-based and non-Qt5-based applications and
> libraries need NOT agree on the location.

I agree this could become a problem for application interaction when
GLib and Qt use different paths, so we should set a common default.

However, do we also want to support interaction between applications
managed by MacPorts and those installed manually?

Rainer