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

piegames <[email protected]>
Newsgroups gmane.linux.xdg.devel
Message-ID <[email protected]>
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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.