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
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
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.
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