Re: [dev] Re: XDG directories

From: Dieter Plaetinck <dieter_AT_plaetinck.be>
Date: Fri, 11 Jun 2010 16:34:28 +0200

On Fri, 11 Jun 2010 16:09:55 +0200
David Engster <deng_AT_randomsample.de> wrote:

> Dieter Plaetinck writes:
> > yes, both the app data and user data (can) end(s) up in
> > $XDG_DATA_HOME
>
> I see that in my .local/share as well. It's a complete mess.
>
> So what they tried to do is to separate configuration settings from
> user data. But then they took a quick look at other systems (like OS
> X) and wanted the possibility to override/add application data (like
> fonts) in a local share hierarchy. I guess they also wanted you to be
> able to install software locally by using '--datadir=~/.local/share
> --sysconfdir=~/.config'. Now you got somehow everything, and every
> application will just do what it deems right, or only implements a
> subset of the spec, so that when you really want to profit from such a
> complicated setup, it probably won't work anyway.

hmm. with application data i meant data generated by the application,
which is somehow related to the user and how the user uses the
application.
i haven't seen data which would usually be in /usr/local (like
binary executables) in ~/.local/, probably because i never installed
anything in there?

 
> > personally I don't mind the mixed nature of data in $XDG_DATA_HOME
> > and as long as apps don't automatically update manually written
> > files, it's all good for me.
>
> The problem is that data is even more spread than it was before, and
> often cannot be tracked anymore to the application which generated
> it. So if you're worried about applications littering your $HOME with
> dotfiles, you now have a littered .local/share and often do not even
> know if you can delete that stuff.
>
> -David
>

I don't find my ~/.local/share problematic. there are only a handful
subdirs which are not app-specific (mime, desktop-directories,
applications, Trash, icons) and it's not a big mystery where they come
from.

Dieter
Received on Fri Jun 11 2010 - 14:34:28 UTC

This archive was generated by hypermail 2.2.0 : Fri Jun 11 2010 - 14:36:02 UTC