Why .local/share ?

[Brian J. Tarricone]

On Wed, 12 Nov 2008 11:10:33 -0500 Liam R E Quin wrote:

> On Tue, 2008-11-11 at 12:01 -0800, Brian J. Tarricone wrote:
> > Liam R E Quin wrote:
> 
> > > You don't want lib or bin in there either -- my login directory
> > > is on a network drive and can be used from machines with differing
> > > CPU architectures.
> > 
> > Then where do you install things like per-user app plugins?
> 
> Certainly nowhere starting with a "." -- I don't want to be
> carrying binaries around in hidden directories in 10 years' time.

Yes, well, seems like current practice for per-user plugin binaries is
in the per-user config dir, which is usually a dot-dir, so this sort of
thing has been around for a while...

> Generally, $HOME/bin/`arch` for binaries, or $HOME/lib/`arch`...
> It can get tricky for things like GIMP plugins.

Yes, but who actually *does* this?  As much as it would be nice if
everyone did, it's rare for an app to consider multi-arch on the same
filesystem.

> >   And when 
> > you want to install an app locally in your home directory where do
> > you install it?
> 
> Sometimes in ~/packages/ -- I want to be able to see them easily :)

Seeing as leading-dot = hidden is merely a convention, this is kinda
silly.  Either you know where something is, or you don't.  Whether or
not you put it in ~/packages, ~/.local, or ~/cheese is irrelevant.

But that's fine!  The whole point of this thread is about possibly
standardising on a few more $XDG_XYZ_DIR and $XDG_XYZ_HOME env vars, so
it would be configurable to whatever you like.  And this could even
solve your multi-arch problem; you could, for example, set:

XDG_LIB_HOME=$HOME/packages/lib/`uname -m`

if you wanted.  But I'd argue, for consistency with other XDG
conventions ($XDG_DATA_HOME), and simplicity (most people won't need or
care about per-arch binary dirs in their homedir), that the *default*
should be $HOME/.local/lib.

	-brian