#928: use XDG_RUNTIME_DIR
---------------------+------------------------------------------------------
Reporter: mccann | Owner: lennart
Type: defect | Status: reopened
Milestone: | Component: daemon
Resolution: | Keywords:
---------------------+------------------------------------------------------
Comment(by coling):
Can I ask if 0.7 is actually released yet? It's not clear from
http://www.freedesktop.org/wiki/Specifications/basedir-spec whether or not
it's actually released yet as it is only available under a "latest
version" link... which kinda implies it's going to be in the next version.
Please note that any patch for this will also have to include support for
falling back and checking the existing runtime dir such that new libpulses
can connect to an older daemon (we actually currently support this with
our even older pre-DoS safe version already, but IMO this older check can
be dropped when support for XDG_RUNTIME_DIR is added - i.e a 2 slot FIFO
;))
Please also note that the [http://standards.freedesktop.org/basedir-
spec/latest/ar01s03.html spec] quite clearly states the properties of the
directory (which align very closely to our own needs - no surprise seeing
as Lennart helped pen the spec!) regarding user permissions, local
filesystem etc:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message.
This is quite different from the requirements of XDG_CACHE_HOME. The
[http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-
Functions.html#g-get-user-runtime-dir Glib docs] state:
On UNIX platforms this is determined using the mechanisms described in
the XDG Base Directory Specification. This is the directory specified in
the XDG_RUNTIME_DIR environment variable. In the case that this variable
is not set, GLib will issue a warning message to stderr and return the
value of g_get_user_cache_dir().
(g_get_user_cache_dir() returns XDG_CACHE_HOME) This is clearly invalid
and thus the glib implementation is very buggy (assuming the docs are
correct).
Are you (mccann) involved upstream? If so can you report this problem to
them and paste a link here? If not, I will do this.
--
Ticket URL: <http://pulseaudio.org/ticket/928#comment:5>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
