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