Why .local/share ?

Brian J. Tarricone bjt23 at cornell.edu
Mon Nov 10 11:16:29 PST 2008


Rodney Dawes wrote:
> On Mon, 2008-11-10 at 11:30 +0100, Thiago Macieira wrote:
>> Orion White wrote:
>>> Hi--
>>>
>>> I've begun to use the XDG base directory standard for my projects, and I
>>> am very happy with it.
>>>
>>> However, I do not understand the rational behind .local/share. I have
>>> searched the Internet for some explanation, but to no avail.
>>>
>>> Why is .local/share not just .local/ or .share/? Why the two levels? And
>>> what is supposed to go in .local/ other than share/?
>> Think of .local/lib, .local/bin, .local/libexec or .local/include. Also 
>> note that many systems already append "share" to their prefixes (/usr, 
>> /usr/local), so it was probably easier to reuse the code.
> 
> Then why ".config" instead of ".local/etc" and ".cache" instead of
> ".local/var/cache"? Shouldn't these directories be under .local as
> well? And shouldn't we define XDG_FOO_HOME variables for the other
> paths? I think an $XDG_LIB_HOME would be particularly useful for
> apps who wish to allow plug-ins to be installed in the user's home
> directory.

That was actually my first thought after reading this thread, but then I 
realised that, if it's somewhat intended for ~/.local to be a place 
where users can install apps with a prefix inside $HOME, you don't want 
(at least) ~/.config in there.  Take for example an app that installs a 
systemwide config file to $(sysconfdir)/xdg/foo-app/configrc.  It 
(probably) expects to save the user's config in 
$XDG_CONFIG_HOME/foo-app/configrc.  Using "normal" xdg basedir lookup 
methods, the "system" file and user file would be the same file, which 
might not be desirable in some situations.

In contrast, files installed to $(datadir) are usually considered 
static, so pointing $XDG_DATA_HOME to ~/.local/share (which might also 
be a user-local $(datadir)) wouldn't be a problem.

However, pointing $XDG_CACHE_HOME to ~/.local/var/cache seems to make 
sense to me (and really, if someone wanted to, there's nothing stopping 
them from setting $XDG_CONFIG_HOME to ~/.local/etc/xdg).

Agree that $XDG_LIB_HOME would be very useful.  I think currently most 
apps that support per-user plugins tend to install them in a 
subdirectory of their configuration dir, which just seems wrong to me. 
A $XDG_BIN_HOME might be useful as well, but I can't think of a use-case 
off the top of my head.

	-brian


More information about the xdg mailing list