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

Mon Feb 8 18:09:19 UTC 2021

Hi Group,

I think "write once" is a poor term for describing the contents of /usr/share.  Moreover, I disagree that the explanation of the intended meaning is an accurate characterization, inasmuch as it focuses on a package manager, as opposed to other administrative tools and agents.  There doesn't even have to be a package manager, though most systems these days do have them.  I would say instead that /usr/share is expected to be modified only by administrative action, not by or on behalf of user processes, and not as part of the routine operation of system services.  I reject the assertion that root is supposed to avoid ever writing to /usr/share directly, though I would accept that doing so should not be considered routine.

XDG_DATA_HOME provides for data files with significance and semantics analogous to those of the contents of /usr/share, with some sense of personal administrative action in place of (system) administrative action.  But it is not restricted to that.  If an application provides for a custom user version of a file whose base version appears in /usr/share, then XDG_DATA_HOME is the place for it. And yes, if an application would normally install its data files to /usr/share when installed as a system application, then XDG_DATA_HOME is the place for them in a personal installation.  But also, XDG_DATA_HOME is a place for application-associated, user-generated or user-modifiable persistent data shared across multiple application instances or among a collection of related applications.  It is neither necessary nor particularly useful to try to distinguish between the last category and the previous ones because these files along belong to the user, not to the system.

I have always supposed that the "share" in the default value of XDG_DATA_HOME was chosen by analogy with /usr/share, but (1) it is only a default, and (2) every analogy has its break-down point.  The analogous default name should not be taken as implying anything outside of what is actually written in the specification.

John Bollinger

________________________________
From: xdg <xdg-bounces at lists.freedesktop.org> on behalf of Sebastian Pipping <sebastian at pipping.org>
Sent: Sunday, February 7, 2021 1:47 PM
To: xdg at lists.freedesktop.org <xdg at lists.freedesktop.org>
Subject: Re: [basedir-spec] XDG_DATA_HOME and reboot-preserved read-write state?

Caution: External Sender. Do not open unless you know the content is safe.

Hi piegames,

On 07.02.21 19:02, piegames wrote:
>> I don't see that in the spec, I just re-checked.  What makes you
>> think
>> it's read-write, more than write-once?  what part/sentences of the
>> spec are your source on that?
>
> Well, the spec states "There is a single base directory relative to
> which user-specific data files should be written. This directory is
> defined by the environment variable $XDG_DATA_HOME." I've never heard
> of something being write-once in this context. What would that be and
> what for?

by write-once I mean the same write-once that applies to /usr/share from
a user point of view: The package manager puts things there through
packages, that's the first write for any file involved.  After that,
nothing but the package manager is supposed to replace or even change
files in /usr/share, right?  (I'm ignoring at cases without a package
manager and/or a technically immutable /usr/share here.)  That's what I
mean by "write-once".

Now the question is whether ~/.local/share has the same semantics or not
and if not, why it's called "share" then.

> Either you have the write permission or you don't and if you
> have it's up to you what and how often you write.

The root user often has write permissions to /usr/share but they are
still not supposed to write to /usr/share directly, as explained above.
 So "can" and "should" are two different pairs of shoes, no?

>> e.g. when XDG_DATA_HOME just contains regular /usr/share
>> like content that is shipped by the upstream application
>
> I think you are misunderstanding the specification. Why should
> XDG_DATA_HOME contain this data?

For instance, because someone installed an application just to its own
user space because they cannot get root permissions or do not want to
install for every single user.

> Everything that is shipped by the
> distribution is already available in the XDG_DATA_DIRS, that's what
> they are for.

As I said: user-specific installation when system-wide installation is
not or not a good option.

> Only relevant data shall be put into XDG_DATA_HOME.

I'm not sure what "relevant" means.

>> What does it take to get a new version of basedir-spec released in
>> general — is that documented somewhere?
>
> Great question. I've opened
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fxdg%2Fxdg-specs%2F-%2Fissues%2F70&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C6d01033bc5a842ef540808d8cbb2f26f%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637483316719766228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t88rgPSh5g3cBmX3EP4ReU2pzUEDL3hwRBPOqXuet%2BY%3D&reserved=0

Cool.

Is commit a0d218ad7da9f01fc5d01867f361aecc5cd61342 considered to be the
official version 0.7?

No comment about my concern about "portable" and "important" in the
current text about XDG_STATE_HOME ?

Best

Sebastian
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fxdg&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C6d01033bc5a842ef540808d8cbb2f26f%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637483316719766228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aSXrxb2cBYOYLGhIb9SPLcU9fmGgEhHxgx34IsyhDAY%3D&reserved=0

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210208/95102792/attachment.htm>