Hi, $XDG_DATA_HOME is for use data storage, and thus read-write. If the spec doesn't make this clear to you, consider proposing a patch that makes the wording more explicit.
The XDG locations only *roughly* mimic the FHS. Don't expect a 1:1 correspondence. For example there is `$XDG_RUNTIME_DIR` which is as far as I understand it a combination of `/tmp` and `/var/run`. There is also `$XDG_STATE_HOME`, a recent addition that has not been released yet. > If (B) then why are apps expected to look for files in XDG_DATA_HOME > and > all of XDG_DATA_DIRS if the defaults for XDG_DATA_DIRS are not > writable > to unprivileged users? Same question: Why are applications expected to look for files in /etc, /var or /usr if they are not writably to unprivilged users? Btw applications are not *expected* to look in XDG_DATA_HOME, but they *can*. The XDG specification mainly talks about locations and what data they should contain, and only little about application specific behavior. piegames On Sun, 2021-02-07 at 04:12 +0100, Sebastian Pipping wrote: > Hi! > > > I am writing to you because I cannot find an answer about something > in > basedir-spec (latest, 0.7 [1]) that seems well within its scope, > yet under-specified and controversial. If you can help me with the > answer, I may be able to help you with the next version of the spec. > > I think it's fair to understand the XDG basedir-spec as the user- > specific equivalent of some core FHS [2] locations, _roughly_: > > FHS XDG variable XDG default > ================================================= > /var/cache XDG_CACHE_HOME $HOME/.cache > /etc XDG_CONFIG_HOME $HOME/.config > /usr/share XDG_DATA_HOME $HOME/.local/share > /var/lock XDG_RUNTIME_DIR /run/user/$USER/ ? > /var/run XDG_RUNTIME_DIR /run/user/$USER/ ? > > Now there are some key locations of FHS that are _not_ in that list, > for instance: > > FHS location Rough rules about content > ================================================= > /var/lib State information; persistent across reboots > /var/log Various logs > /var/spool Queue of tasks waiting to be processed > /var/tmp Temporary files to be preserved between reboots > > > _Maybe_ it's okay that these are not in XDG, _maybe_ that's a > feature, > but the spec doesn't seem to say. > > More specifically, the spec does not seem to say whether > XDG_DATA_HOME > ($HOME/.local/share) should > > (A) have the same read-only/write-once semantic that we know from > /usr/share and /usr/local/share > > or > > (B) be the home to all sorts of long-lived read-write state data > (like you would expect from /var/lib for when things are less > user-specific). > > The common use of the word "share" in $HOME/.local/share and > /usr/share > seems to support (A) but then where does all the long-lived _read- > write_ > state data go? (The spec is clear that XDG_RUNTIME_DIR is not the > answer here (..).) > > If (B) then why are apps expected to look for files in XDG_DATA_HOME > and > all of XDG_DATA_DIRS if the defaults for XDG_DATA_DIRS are not > writable > to unprivileged users? > > > I'm not the first [3] to wonder about this, yet I only see ideas, > guessing and discussions, no bulletproof answers. That's the job of > a > spec, right? > > So I am hoping for a version 0.8 of the spec that says > > - where read-write state files that should survive reboots should > go, > and > > - how much of a catch-all pot XDG_DATA_HOME should be or not be, > and > > - if ~/.local/var/lib/ is something that XDG is concerned about > and has different ideas for. > > That would be awesome for future discussions and decision making in > free > software projects. Many thanks in advance! > > Best > > > > Sebastian > > > [1] > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > [2] https://refspecs.linuxfoundation.org/fhs.shtml > [3] https://wiki.debian.org/XDGBaseDirectorySpecification#state > _______________________________________________ > xdg mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
