On 19/02/14 13:03, Ryan Lortie wrote: > 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.
This is a significant policy change. At the moment, ~/.local/share has a dual role as the home-directory equivalent of both /usr/share and /var/lib, and is considered to be the right place for user data in non-document-oriented applications (anything that insta-saves automatically and doesn't use a Save As dialog), for instance: * Rhythmbox playlists * Tomboy notes * Telepathy (Mission Control) accounts * Telepathy IM logs * the Tracker database * the Evolution address book, calendar etc. (all of those are non-hypothetical: they exist in my ~/.local/share) A rule of thumb from <http://ploum.net/207-modify-your-application-to-use-xdg-folders/>: > But how do you know what goes in what folder ? > > There’s a little trick : just imagine that it was deleted. What would > you think as a user ? > > If you would cry, running frenetically to your backup, it means that > it belongs to XDG_DATA_HOME. > > If you would think “Damn, I will have to reconfigure all”, it belongs > to $XDG_CONFIG_HOME. [...] > > If you would just think “It’s bloody slow those days” then it is > obviously part of XDG_CACHE_HOME. Ryan wrote: > 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." People who put their ~/.config in a VCS are going to hate that change, and so are people who use deletion of ~/.config as a "factory reset" (but don't want to lose, e.g., their Tomboy notes). If the authors of a particular application don't want to distinguish between configuration and data, that's a feature-request bug that might reasonably be WONTFIX, but I think XDG_DATA_HOME is a better fallback for such applications than XDG_CONFIG_HOME. > 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). I assume service/daemon/behind-the-scenes things like dconf, Telepathy, GNOME Online Accounts, etc. count as OS components for these purposes? > 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.). ~/.lib/i386-linux-gnu :-P > 2) ~/.local/share/Trash/ is weird It's weird in a "~/.local/share is the user's /usr/share" world-view. In a world-view that says "~/.local/share is a hybrid of /usr/share and /var/lib" it's perfectly normal: if Trash was a system service, it would be correct for trashed files to go in /var/lib/Trash or something. S _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg