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

[piegames]

Hi

> by write-once I mean the same write-once that applies to /usr/share
> from a user point of view

I agree with most of what John Bollinger said there.

However, I'd like to add one point about user-local installations,
because you are talking a lot about it. I am conviced that installing
an application with a prefix pointing somewhere into home is an
absolute niche case. Most systems are single-user anyway, so if you
simply want to get around your package manager, /usr/local probably is
a better place. Most software installed in HOME actually comes from
third-party package managers. Asking where they should which data where
is a good question, especially because the specification is a bit weak
on their use cases. That's part of the reason so few of them adhere to
it.

> > Only relevant data shall be put into XDG_DATA_HOME.
> I'm not sure what "relevant" means.

Basically everything that's worth space on my backup. If I have some
software installtions in XDG_DATA_HOME I won't be angry, but the better
way IMO is to put that data into XDG_CACHE_HOME and only store the
registry database in XDG_DATA_HOME.

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

With "portable", I was meaning "bound to the specific
machine/installation" in the broadest sense. Regarding "important", see
"relevant" above.

> What do you think about dropping the bit about importance and making
> "portable" more precise, i.e. that two machines should have their own
> copy or so?

I won't stop you. But I'm fine with the current wording and I'm simply
happy that the XDG_STATE_HOME got merged. If I've learned one thing
from that contribution: this spec isn't a "I have a nice idea let's
formalize it". It's more a "let's look at how people do things and
write down the common ground of things that worked well". So my
suggestion is to wait a few years until some applications actually use
XDG_STATE_HOME, and then have a look at them before making any
adjustments to the spec.


piegames

On Sun, 2021-02-07 at 20:47 +0100, Sebastian Pipping wrote:
> 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://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/70
> 
> 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://lists.freedesktop.org/mailman/listinfo/xdg