volatile config data and XDG Base Directory spec

[Jerome Leclanche]

Hi,

On Wed, Feb 19, 2014 at 1:03 PM, Ryan Lortie <desrt at desrt.ca> wrote:
> hi,
>
> On Wed, Feb 19, 2014, at 7:40, Simon McVittie wrote:
>> I agree that storing state in ~/.config is a bug, but I think that's a
>> misuse of existing categories rather than a need for a new category -
>> why wouldn't ~/.local/share be OK? - and I don't think adding new
>> categories is going to reduce developer confusion/misuse between
>> categories.
>
> Lennart and I had a discussion about this at GUADEC and we came to the
> opposite conclusion.
>
> I'll write down here what I got out of that discussion, but I think we
> mostly agree.
>
> The message that we want to send is "if in doubt, use ~/.config/".
>
> Specifically, we feel that things should only be "installed" into
> ~/.local/share/.  Things like fonts, plugins, desktop files, dbus
> service files, icons, themes, etc. -- essentially things that you would
> also find in /usr/share if the sysadmin had installed them instead.  I
> find this symmetry to be very nice -- and particularly it means that
> XDG_DATA_HOME and XDG_DATA_DIRS would then mean the same thing, and I
> would be comfortable modifying the spec to be much more strongly-worded
> with regards to how you should always use both for the same purpose
> (when reading).
>
> I think ~/.config/ is a bit of a weird name for "toss all of the data
> here", but so is ~/Library/.  ~/.config/ is established.  You also have
> things like dconf that are storing data here that is definitely
> configuration, but also kinda not the sort of "config" you'd expect in
> /etc -- ie: you couldn't go in there and edit it with a text editor.
> Another example of something that feel a little more state-like but not
> exactly config: ~/.config/monitors.xml.
>
> In general, I'd like to tell people that "If your program wants to
> install things like plugins|fonts|etc, put them in XDG_DATA_HOME.  All
> other state goes in XDG_CONFIG_HOME.  This includes things like
> databases and game state and save files."

Very, very strongly agreed with all this for exactly the reasons you
highlighted.


>
> We'd also like to tell people that applications putting data in
> ~/.config/ are expected to use the D-Bus style naming scheme to select a
> directory for themselves.  We would enforce this for sandboxed
> applications. OS components would be exempted from this restriction
> (both as a matter of policy and enforcement).
>
> In general, it is expected that you do not place such a subdirectory in
> ~/.local/share/ -- rather you would install into one of the "well know"
> directories for fonts, etc.  An exception is if your program has
> something like plugins and you have a system directory for that as well
> -- then you could name this in the D-Bus style.

Agreed in general but I'm not sure if entirely dropping the legacy
definition of ~/.local/share is wise.
As long as actual configuration is stored in ~/.config, and actual
cache is stored in ~/.cache, I have no problem with applications using
~/.local/share as their everything-else-dump. Looking at what's in my
/usr/share right now ... it does act as a systemwide "I didn't know
where else to put this" dump. Maybe we can rename the variable to
$XDG_TOSS_IT_WHERE_THERE_IS_ROOM_DIRS. But yes, agreed with the
general idea.
Are you moving towards requiring dbus-style naming? I'm ok with
encouraging it, but not ok with requiring it. Of course, if two apps
conflict, they should move (both of them, and having to handle
migration becomes their own fault for not following the
recommendation).


>
> The main thrust behind this conclusion is that we've had a lot of people
> from a wide range of areas (everyone from game developers to Firefox)
> telling us that the current split of "config" vs. "data" is very
> difficult for them to support and not something that they have on other
> platforms.  I agree that adding another directory would not help here.
> Blessing "just use ~/.config" as the official way forward would help
> these people a lot.

This is also the feedback I hear from a lot of people. It's also kinda
what they already do, so the cat is already out of that bag.
People use ~/.config for everything and the apps that don't follow xdg
have a single unsplittable directory. Being able to tell them "go
ahead and just move it to ~/.config" is a lot easier.


>
> A couple of caveats:
>
> 1) I mention "plugins" above while talking about "share".  This should
> set off alarm bells -- maybe we could also reopen the ~/.lib/x86/ vs.
> ~/.lib/amd64/ etc. debate (but we should keep that a separate discussion
> from this, imho.).
>
> 2) ~/.local/share/Trash/ is weird, and thinking about this, would we
> honestly expect to have this in ~/.config/?  I think that this folder is
> truly unique, and putting it in the location that it has now was
> probably not a great choice... I think we could just leave it there and
> acknowledge that it's weird.

It was in ~/.Trash at some point, wasn't it? In hindsight, it was just
fine there and it probably shouldn't have been moved, but it's not
really problematic in ~/.local/share either.

>
> Cheers
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg