xpra icon
Bug tracker and wiki

Opened 12 months ago

Closed 6 months ago

Last modified 6 months ago

#1723 closed task (fixed)

move to xdg base directory specification

Reported by: Antoine Martin Owned by: J. Max Mena
Priority: major Milestone: 2.4
Component: platforms Version: 2.2.x
Keywords: Cc: dennis.schridde@…

Description (last modified by Antoine Martin)

Now that we've moved sockets and log files to $XDG_RUNTIME_DIR (see #1129), we could move the config files to $XDG_CONFIG_HOME (.config/.

We will probably have to support the old location for quite some time, if not indefinitely.
We can load the old location first, then override with the new one - if any are present.

Change History (5)

comment:1 Changed 12 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 7 months ago by Antoine Martin

Milestone: 3.02.4

comment:3 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

Specification: XDG Base Directory Specification.

Done in r19741, we now look for paths:

  • the html5 client in XDG_DATA_DIRS + xpra/www (typically: /usr/local/share/xpra/www or /usr/share/xpra/www})
  • same for xpra resources (icons, etc), ie: .. /xpra/icons
  • ppd filters in XDG_DATA_DIRS + some subdirs thereof
  • xpra user config files in XDG_CONFIG_HOME, typically: ~/.config/xpra, we still load the legacy location ~/.xpra/ if it exists for backwards compatibility
  • we no longer write sockets or log files in ~/.xpra - though this can be re-enabled with XPRA_LEGACY_DOTXPRA=1
  • the system-wide config files are loaded from /etc/xpra / /usr/local/etc/xpra and the new XDG_CONFIG_DIRS (typically /etc/xdg/xpra - but the packaging has not been changed so we still use /etc/xpra, I expect too much breakage with third party packaging if we moved to /etc/xdg/xpra right away.

Note: by being more "standards compliant", the behaviour may have changed slightly in some cases: we may load files from /usr/local if they exist whereas we would not have done so previously. This should not be a problem in most cases, as only custom installations place files there.

New output from the paths script:

$ ./xpra/platform/paths.py 
* app
  - default
    - dir                         : /usr/share/xpra
* default_conf
  - dirs                          : []
* download
  - dir                           : ~/Downloads
* home                            : /home/antoine
* icons                           : /usr/share/xpra/icons
* install
  - prefix                        : /usr
* libexec
  - dir                           : /usr/libexec/
* log
  - dirs                          : /run/user/$UID/xpra, /tmp
* mmap
  - dir                           : /run/user/$UID/xpra
* nodock_command                  : xpra
* resources                       : /usr/share/xpra
* socket
  - dirs                          : /run/user/$UID/xpra, /run/xpra
* sound_command                   : xpra
* sshpass_command                 : /usr/bin/sshpass
* system_conf
  - dirs                          : /etc/xpra, /usr/local/etc/xpra, /etc/xdg/xpra
* user_conf
  - dirs                          : ~/.xpra, ~/.config/xpra
* xpra-tmp
  - dir                           : /run/user/$UID/xpra/tmp

We can now nuke ~/.xpra and it should never be re-created by running the client or the server.

Some code and scripts may still look for files there, but they should all continue to work without.
(this does not apply to versions older than 0.17 which only look for run-xpra in ~/.xpra by default - but those have been EOL for a while now, see ticket:1129#comment:8)

@maxmylyn: FYI, feel free to close.

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 months ago by J. Max Mena

Resolution: fixed
Status: newclosed

Noted and closing.

comment:5 Changed 6 months ago by urzds

Cc: dennis.schridde@… added
Note: See TracTickets for help on using tickets.