Re: Fwd: why not XDG_PREFIX_HOME

Okay I do agree that breaking change, so I think
XDG_CONFIG_HOME/XDG_CACHE_HOME can remained unchanged, also all dirs can
have their directories after realization of the fact. I think we could
instead as rhkramer said, all default new directories added to the
relative to an another variable call XDG_PREFIX_HOME which defaults to
~/.local. I think is could be useful since it act as /usr for user
packages. Also this has been brought up before, but can we also add
state dir.


On 15/09/2017 20:25, [email protected] wrote:
> On Friday, September 15, 2017 07:45:14 AM Johannes Löthberg wrote:
>> Hey,
>>
>> Quoting Marc Boocha (2017-08-30 10:37:44)
>>
>>> Instead having an XDG_BIN_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, we should
>>> have a single XDG_PREFIX_HOME. This will be located as ~/.local. 
> I don't agree with the proposal, but, most especially, ~/.local might be the 
> default, but should be easily changeable.  (Also, maybe the default should be 
> in terms of another environment variable ($HOME) instead of to an explicit 
> location.)
>
> See below.
>
>>> Since
>>> make install or package manger normal produce these directories, have
>>> separate environmental variables is not needed.
>>>
>>> XDG_BIN_HOME is equivalent to XDG_PREFIX_HOME/bin
>>>
>>> XDG_CONFIG_HOME is equivalent to XDG_PREFIX_HOME/etc (currently ~/.config
>>> although I feel this is more logical)
>>>
>>> XDG_DATA_HOME is equivalent to XDG_PREFIX_HOME/share
>>>
>>> This conserves the number of environmental variable used and makes it
>>> easy to add extensions like headers and libraries.
>>>
>>> Also since XDG_BIN_DIRS is same as PATH, why is it even needed
>> While that might be more consistent with the global directories and
>> potentially nicer, I have no plans of making breaking changes to the
>> spec that would be much less likely to be adopted.  And you'd end up
>> having all of them set for likely years before a significant portion of
>> software did adopt it.  
>> Some people still would want to have things
>> separate, or named differently, so we would still need the old variables
>> as well, which would just add more cruft to the spec.  
> +1
>
>
>> Environment
>> variables are cheap, not really a precious resource we need to preserve.
> _______________________________________________
> xdg mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/xdg


_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg