Joerg Barfurth jub at sun.com
Fri Nov 19 11:18:25 EET 2004

C. Gatzemeier wrote:
> Am Tuesday 26 October 2004 14:50 schrieb Waldo Bastian:

>>>XDG_DATA_HOME defaulting to $HOME/.local/share raises another question.
>>It's the user's equivalent of /usr/local
>>Note that /usr is often imported over the network rather than local.
> Allright, from that direction it is understandable where it comes from.
> I see mainly two possible ways to stack those dirs in network setups:
> Either /usr is imported from a server and /usr/local is actually a local 
> partition with machine specific apps.
> Or /usr is a local partition and /usr/local is imported as the "stuff 
> installed for/on the *local site/network*".

The question is what "local" means here. It clearly does not mean 
unsharable (i.e. specific to one host).

> The question probably becomes: "Do we also need this kind of stacking within 
> the user specific scope?
> Assuming $HOME would not need "local" mounts below it, wouldn't ~/.usr with 
> ~/.usr/share for things common to different apps below it seem appropriate?

I'm not sure the concept of /usr - which is a sharable, but 
fundamentally read-only location - really applies to home directories. 
Stuff that is installed and can simply be picked up as is by user just 
resides outside of $HOME.

There could be an equvalent of /usr/local. That would be a place to 
install user-specific software. Maybe $HOME/usr would be a good name, if 
we want to standardize. But that is not directly related to stacking of 
file systems.

One issue remains though: $HOME is shared not only among hosts, but also 
independent of OS and arch. A $HOME/usr needs to support multiple 
systems, whereas the equvalent of /usr/share (which currently appears to 
be $HOME/.local/share in the basedir spec) can be shared even among 

> Well now that I think of it, with user mountable filesystems (like lufs?)  
> mounting say your things from your home computer or your usbkey to 
> ~/.usr/local could still work.

If you want to mount "your things" as a user, you would probably not 
mount them to a hidden place - so no dot-directory. Here something like 
/home/mnt would make more sense. But I am not really convinced we need 

Nevertheless I think we need some place to support stacking of 
filesystems within home - to provide an unsharable (between hosts) 
per-user location. More on this in a separate post.

> What about considering ~/.usr as default for $XDG_DATA_HOME and mentioning the 
> use of /share subdirectories for common things in the spec (for themes, 
> icons, trash etc.).
> The next question is if it does make any sense to distinguish between /.usr 
> and /.var below $HOME or if both could be combined maybe in ~/.data. OTOH 
> maybe there really is a reason for separation or /.var is not necessary for 
> the spec because things that would go in there tend to go directly under 
> $HOME.

Yes. Basically $HOME is a place for data that can be changed any time 
(by the user), so putting stuff that would go under /var if 
user-independent directly under $HOME (as dot-directories is the right 
thing to do.

Personally I don't think reusing all the historic unix names for 
subdivisions of home is really the best choice, as many users can't 
relate to them. So to me ~/.config and ~/.data look much better than 
~/.etc or ~/.usr. This applies even more to any non-dot subdirectories.

Ciao, Joerg

Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
OpenOffice.org Configuration          http://util.openoffice.org

More information about the xdg mailing list