[basedir-spec] XDG_DATA_HOME and reboot-preserved read-write state?
piegames
piegames at darmstadt.ccc.de
Sun Feb 7 11:20:46 UTC 2021
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
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
More information about the xdg
mailing list