Re: [basedir-spec] XDG_DATA_HOME and reboot-preserved read-write state?

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