[PATCH 0/2] XDG basedir bin dirs

[Johannes Löthberg]

I've had some old patches around for the XDG basedir spec, and figured I
might as well finally send them in and see what people think.

The first one just reformats some text and fixes some inconsistent
indentation, so should be pretty uncontroversial.

The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

Any comments welcome!

Johannes Löthberg (2):
basedir: Reformat text and indentation, fix inconsistent hyphenation
basedir: Add XDG_BIN_HOME and XDG_BIN_DIRS

basedir/basedir-spec.xml | 107 ++++++++++++++++++++++++++++++++---------------
1 file changed, 74 insertions(+), 33 deletions(-)

[Johannes Löthberg]

* Reformat and reindent the text and use spaces exclusively instead of
mixed tabs and spaces. (Spaces choosen since the majority of lines
were space indented.)

* Make hyphenation of 'user-specific' more consistent.
---
basedir/basedir-spec.xml | 67 ++++++++++++++++++++++++------------------------
1 file changed, 34 insertions(+), 33 deletions(-)

diff --git a/basedir/basedir-spec.xml b/basedir/basedir-spec.xml
index 8e6fff6..eefbe2b 100644
--- a/basedir/basedir-spec.xml
+++ b/basedir/basedir-spec.xml
@@ -1,6 +1,6 @@
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
- ]>
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
+ ]>
<article id="index">
<articleinfo>
<title>XDG Base Directory Specification</title>
@@ -8,31 +8,31 @@
<pubdate>24th November 2010</pubdate>
<authorgroup>
<author>
- <firstname>Waldo</firstname>
- <surname>Bastian</surname>
- <affiliation>
- <address>
- <email>***@kde.org</email>
- </address>
- </affiliation>
+ <firstname>Waldo</firstname>
+ <surname>Bastian</surname>
+ <affiliation>
+ <address>
+ <email>***@kde.org</email>
+ </address>
+ </affiliation>
</author>
<author>
- <firstname>Ryan</firstname>
- <surname>Lortie</surname>
- <affiliation>
- <address>
- <email>***@desrt.ca</email>
- </address>
- </affiliation>
+ <firstname>Ryan</firstname>
+ <surname>Lortie</surname>
+ <affiliation>
+ <address>
+ <email>***@desrt.ca</email>
+ </address>
+ </affiliation>
</author>
<author>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <affiliation>
- <address>
- <email>***@poettering.net</email>
- </address>
- </affiliation>
+ <firstname>Lennart</firstname>
+ <surname>Poettering</surname>
+ <affiliation>
+ <address>
+ <email>***@poettering.net</email>
+ </address>
+ </affiliation>
</author>
</authorgroup>
</articleinfo>
@@ -100,24 +100,25 @@
</itemizedlist>
</para>

- <para>All paths set in these environment variables must be
- absolute. If an implementation encounters a relative path in any
- of these variables it should consider the path invalid and ignore
- it.</para>
+ <para>
+ All paths set in these environment variables must be
+ absolute. If an implementation encounters a relative path in any
+ of these variables it should consider the path invalid and ignore
+ it.
+ </para>
</sect1>

-
<sect1 id="variables">
<title>Environment variables</title>
<para>
<literal>$XDG_DATA_HOME</literal> defines the base directory relative to
- which user specific data files should be stored. If
+ which user-specific data files should be stored. If
<literal>$XDG_DATA_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.local/share should be used.
</para>
<para>
<literal>$XDG_CONFIG_HOME</literal> defines the base directory relative to
- which user specific configuration files should be stored. If
+ which user-specific configuration files should be stored. If
<literal>$XDG_CONFIG_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.config should be used.
</para>
@@ -156,7 +157,7 @@
</para>
<para>
<literal>$XDG_CACHE_HOME</literal> defines the base directory relative to
- which user specific non-essential data files should be stored. If
+ which user-specific non-essential data files should be stored. If
<literal>$XDG_CACHE_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.cache should be used.
</para>
@@ -219,7 +220,7 @@
</listitem>
<listitem>
<para>
- A user specific version of the data file may be created in
+ A user-specific version of the data file may be created in
<literal>$XDG_DATA_HOME</literal>/subdir/filename, taking into
account the default value for <literal>$XDG_DATA_HOME</literal> if
<literal>$XDG_DATA_HOME</literal> is not set.
@@ -249,7 +250,7 @@
</listitem>
<listitem>
<para>
- A user specific version of the configuration file may be created in
+ A user-specific version of the configuration file may be created in
<literal>$XDG_CONFIG_HOME</literal>/subdir/filename, taking into
account the default value for <literal>$XDG_CONFIG_HOME</literal> if
<literal>$XDG_CONFIG_HOME</literal> is not set.

[Johannes Löthberg]

---
basedir/basedir-spec.xml | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)

diff --git a/basedir/basedir-spec.xml b/basedir/basedir-spec.xml
index eefbe2b..e44e020 100644
--- a/basedir/basedir-spec.xml
+++ b/basedir/basedir-spec.xml
@@ -34,6 +34,15 @@
</address>
</affiliation>
</author>
+ <author>
+ <firstname>Johannes</firstname>
+ <surname>Löthberg</surname>
+ <affiliation>
+ <address>
+ <email>***@kyriasis.com</email>
+ </address>
+ </affiliation>
+ </author>
</authorgroup>
</articleinfo>

@@ -66,6 +75,20 @@
environment variable <literal>$XDG_CONFIG_HOME</literal>.
</para>
</listitem>
+ <listitem>
+ <para>
+ There is a single base directory relative to which user-specific
+ executable files should be written. This directory is defined by the
+ environment variable <literal>$XDG_BIN_HOME</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ There is a set of preference ordered base directories relative to
+ which executable files should be searched. This set of directories
+ is defined by the environment variable <literal>$XDG_BIN_DIRS</literal>.
+ </para>
+ </listitem>
<listitem>
<para>
There is a set of preference ordered base directories relative to
@@ -122,6 +145,12 @@
<literal>$XDG_CONFIG_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.config should be used.
</para>
+ <para>
+ <literal>$XDG_BIN_HOME</literal> defines the base directory relative to
+ which user-specific executable files should be stored. If
+ <literal>$XDG_BIN_HOME</literal> is either not set or empty, a default equal to
+ <literal>$HOME</literal>/.local/bin should be used.
+ </para>
<para>
<literal>$XDG_DATA_DIRS</literal> defines the preference-ordered set of
base directories to search for data files in addition to the
@@ -144,6 +173,17 @@
If <literal>$XDG_CONFIG_DIRS</literal> is either not set or empty, a value equal to
/etc/xdg should be used.
</para>
+ <para>
+ <literal>$XDG_BIN_DIRS</literal> defines the preference-ordered set of
+ base directories to search for executable files in addition to the
+ <literal>$XDG_BIN_HOME</literal> base directory.
+ The directories in <literal>$XDG_BIN_DIRS</literal> should be seperated
+ with a colon ':'.
+ </para>
+ <para>
+ If <literal>$XDG_BIN_DIRS</literal> is either not set or empty, a value equal to
+ /usr/local/bin:/usr/bin should be used.
+ </para>
<para>
The order of base directories denotes their importance; the first
directory listed is the most important. When the same information is

[Lennart Poettering]

Post by Johannes Löthberg
+ <listitem>
+ <para>
+ There is a set of preference ordered base directories relative to
+ which executable files should be searched. This set of directories
+ is defined by the environment variable <literal>$XDG_BIN_DIRS</literal>.
+ </para>
+ </listitem>

This appears redundant, given that there's already $PATH which pretty
much does this. I think instead of the above there should be a brief
comment, that $PATH is the search counterpart here...

Post by Johannes Löthberg
<listitem>
<para>
There is a set of preference ordered base directories relative to
@@ -122,6 +145,12 @@
<literal>$XDG_CONFIG_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.config should be used.
</para>
+ <para>
+ <literal>$XDG_BIN_HOME</literal> defines the base directory relative to
+ which user-specific executable files should be stored. If
+ <literal>$XDG_BIN_HOME</literal> is either not set or empty, a default equal to
+ <literal>$HOME</literal>/.local/bin should be used.
+ </para>

A problem with ~/.local/bin is that $HOME might be shared between
systems of different archs, and thus any compiled binaries dropped in
this dir might cause problems when used from other systems. I don't
think this issue is reason enough not to have ~/.local/bin, in
particular as many distros and systems already have it and it is a
good idea to document what is already established, but I am very sure
the spec should document the issue at least, and maybe suggests that
scripts rather than arch-specific binaries are preferably placed
there, or that if arch-specific binaries are placed there $HOME
becomes arch-specific to some degree, which is probably not even a
problem in 99.9% of the cases, and hence acceptable in the local case.

Lennart

[Johannes Löthberg]

---
Dropped XDG_BIN_DIRS and add note about architecture-specificity of HOME
due to XDG_BIN_HOME.

basedir/basedir-spec.xml | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

diff --git a/basedir/basedir-spec.xml b/basedir/basedir-spec.xml
index eefbe2b..9d001d8 100644
--- a/basedir/basedir-spec.xml
+++ b/basedir/basedir-spec.xml
@@ -34,6 +34,15 @@
</address>
</affiliation>
</author>
+ <author>
+ <firstname>Johannes</firstname>
+ <surname>Löthberg</surname>
+ <affiliation>
+ <address>
+ <email>***@kyriasis.com</email>
+ </address>
+ </affiliation>
+ </author>
</authorgroup>
</articleinfo>

@@ -66,6 +75,13 @@
environment variable <literal>$XDG_CONFIG_HOME</literal>.
</para>
</listitem>
+ <listitem>
+ <para>
+ There is a single base directory relative to which user-specific
+ executable files should be written. This directory is defined by the
+ environment variable <literal>$XDG_BIN_HOME</literal>.
+ </para>
+ </listitem>
<listitem>
<para>
There is a set of preference ordered base directories relative to
@@ -122,6 +138,18 @@
<literal>$XDG_CONFIG_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.config should be used.
</para>
+ <para>
+ <literal>$XDG_BIN_HOME</literal> defines the base directory relative to
+ which user-specific executable files should be stored. If
+ <literal>$XDG_BIN_HOME</literal> is either not set or empty, a default equal to
+ <literal>$HOME</literal>/.local/bin should be used.
+ </para>
+ <para>
+ Since <literal>$HOME</literal> might be shared between systems of different achitectures,
+ installing compiled binaries to <literal>$XDG_BIN_HOME</literal> could cause problems when
+ used on systems of differing architectures. This is often not a problem, but the fact that
+ <literal>$HOME</literal> becomes partially achitecture-specific should be kept in mind.
+ </para>
<para>
<literal>$XDG_DATA_DIRS</literal> defines the preference-ordered set of
base directories to search for data files in addition to the

[Josh Triplett]

Post by Johannes Löthberg
---
Dropped XDG_BIN_DIRS and add note about architecture-specificity of HOME
due to XDG_BIN_HOME.

This version of the proposal looks great to me, and thank you for
working on this.

Reviewed-by: Josh Triplett <***@joshtriplett.org>

If this gets accepted, I would be happy to help work with various
projects to incorporate support for it. Unlike the other variables, I
think this only needs special support from software that *installs*
binaries to $XDG_BIN_HOME (falling back to ~/.local/bin), and not
software that just wants to access such files (for which it should use
$PATH).

I don't think this needs to be put in the standard, but people who want
to make $HOME less architecture-specific might want to set $XDG_BIN_HOME
to a path that includes the architecture triple, similar to multiarch
library paths.

Post by Johannes Löthberg
basedir/basedir-spec.xml | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/basedir/basedir-spec.xml b/basedir/basedir-spec.xml
index eefbe2b..9d001d8 100644
--- a/basedir/basedir-spec.xml
+++ b/basedir/basedir-spec.xml
@@ -34,6 +34,15 @@
</address>
</affiliation>
</author>
+ <author>
+ <firstname>Johannes</firstname>
+ <surname>Löthberg</surname>
+ <affiliation>
+ <address>
+ </address>
+ </affiliation>
+ </author>
</authorgroup>
</articleinfo>
@@ -66,6 +75,13 @@
environment variable <literal>$XDG_CONFIG_HOME</literal>.
</para>
</listitem>
+ <listitem>
+ <para>
+ There is a single base directory relative to which user-specific
+ executable files should be written. This directory is defined by the
+ environment variable <literal>$XDG_BIN_HOME</literal>.
+ </para>
+ </listitem>
<listitem>
<para>
There is a set of preference ordered base directories relative to
@@ -122,6 +138,18 @@
<literal>$XDG_CONFIG_HOME</literal> is either not set or empty, a default equal to
<literal>$HOME</literal>/.config should be used.
</para>
+ <para>
+ <literal>$XDG_BIN_HOME</literal> defines the base directory relative to
+ which user-specific executable files should be stored. If
+ <literal>$XDG_BIN_HOME</literal> is either not set or empty, a default equal to
+ <literal>$HOME</literal>/.local/bin should be used.
+ </para>
+ <para>
+ Since <literal>$HOME</literal> might be shared between systems of different achitectures,
+ installing compiled binaries to <literal>$XDG_BIN_HOME</literal> could cause problems when
+ used on systems of differing architectures. This is often not a problem, but the fact that
+ <literal>$HOME</literal> becomes partially achitecture-specific should be kept in mind.
+ </para>
<para>
<literal>$XDG_DATA_DIRS</literal> defines the preference-ordered set of
base directories to search for data files in addition to the
--
2.14.1

[Lennart Poettering]

Post by Josh Triplett

Post by Johannes Löthberg
---
Dropped XDG_BIN_DIRS and add note about architecture-specificity of HOME
due to XDG_BIN_HOME.

This version of the proposal looks great to me, and thank you for
working on this.
If this gets accepted, I would be happy to help work with various
projects to incorporate support for it. Unlike the other variables, I
think this only needs special support from software that *installs*
binaries to $XDG_BIN_HOME (falling back to ~/.local/bin), and not
software that just wants to access such files (for which it should use
$PATH).
I don't think this needs to be put in the standard, but people who want
to make $HOME less architecture-specific might want to set $XDG_BIN_HOME
to a path that includes the architecture triple, similar to multiarch
library paths.

Looks fine to me too. IIRC I have commit access to the git repo, hence
I might commit this eventually (ping me in two weeks about this if
nobody else took care of this yet). However, before that happens I
think we should wait for more replies, maybe others have opinions
about this too, for example I am interested in Allison Lortie's
opinions on this (added to CC), I know she has some interest in the
basedir stuff, too.

Allison, any chance you can comment?

Lennart

[Marc Boocha]

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



Regards

Marc Boocha



*From: *Lennart Poettering <***@0pointer.de>
*Sent: *30 August 2017 16:23
*To: *Josh Triplett <***@joshtriplett.org>
*Cc: ****@lists.freedesktop.org
*Subject: *Re: [PATCH v2 2/2] basedir: Add XDG_BIN_HOME

Post by Josh Triplett

Post by Johannes Löthberg
---
Dropped XDG_BIN_DIRS and add note about architecture-specificity of HOME
due to XDG_BIN_HOME.

This version of the proposal looks great to me, and thank you for
working on this.
If this gets accepted, I would be happy to help work with various
projects to incorporate support for it. Unlike the other variables, I
think this only needs special support from software that *installs*
binaries to $XDG_BIN_HOME (falling back to ~/.local/bin), and not
software that just wants to access such files (for which it should use
$PATH).
I don't think this needs to be put in the standard, but people who want
to make $HOME less architecture-specific might want to set $XDG_BIN_HOME
to a path that includes the architecture triple, similar to multiarch
library paths.

Looks fine to me too. IIRC I have commit access to the git repo, hence

I might commit this eventually (ping me in two weeks about this if

nobody else took care of this yet). However, before that happens I

think we should wait for more replies, maybe others have opinions

about this too, for example I am interested in Allison Lortie's

opinions on this (added to CC), I know she has some interest in the

basedir stuff, too.



Allison, any chance you can comment?



Lennart
--
Lennart Poettering, Red Hat

_______________________________________________

xdg mailing list

***@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/xdg

[Thiago Macieira]

Post by Marc Boocha
XDG_CONFIG_HOME is equivalent to XDG_PREFIX_HOME/etc (currently ~/.config
although I feel this is more logical)

Are you proposing we change the default now, 15 years later?

[Johannes Löthberg]

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. 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. Environment
variables are cheap, not really a precious resource we need to preserve.

[r***@gmail.com]

Post by Johannes Löthberg
Hey,
Quoting Marc Boocha (2017-08-30 10:37:44)

Post by Marc Boocha
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.

Post by Johannes Löthberg

Post by Marc Boocha
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

Post by Johannes Löthberg
Environment
variables are cheap, not really a precious resource we need to preserve.

[Marc Boocha]

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.

Post by r***@gmail.com

Post by Johannes Löthberg
Hey,
Quoting Marc Boocha (2017-08-30 10:37:44)

Post by Marc Boocha
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.

Post by Johannes Löthberg

Post by Marc Boocha
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

Post by Johannes Löthberg
Environment
variables are cheap, not really a precious resource we need to preserve.

_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[Johannes Löthberg]

Quoting Lennart Poettering (2017-08-30 10:23:06)

Post by Lennart Poettering
Looks fine to me too. IIRC I have commit access to the git repo, hence
I might commit this eventually (ping me in two weeks about this if
nobody else took care of this yet). However, before that happens I
think we should wait for more replies, maybe others have opinions
about this too, for example I am interested in Allison Lortie's
opinions on this (added to CC), I know she has some interest in the
basedir stuff, too.
Allison, any chance you can comment?

Two week ping.

[Johannes Löthberg]

Quoting Lennart Poettering (2017-08-30 10:23:06)

Post by Lennart Poettering

Post by Josh Triplett

Post by Johannes Löthberg
---
Dropped XDG_BIN_DIRS and add note about architecture-specificity of HOME
due to XDG_BIN_HOME.

This version of the proposal looks great to me, and thank you for
working on this.
If this gets accepted, I would be happy to help work with various
projects to incorporate support for it. Unlike the other variables, I
think this only needs special support from software that *installs*
binaries to $XDG_BIN_HOME (falling back to ~/.local/bin), and not
software that just wants to access such files (for which it should use
$PATH).
I don't think this needs to be put in the standard, but people who want
to make $HOME less architecture-specific might want to set $XDG_BIN_HOME
to a path that includes the architecture triple, similar to multiarch
library paths.

Looks fine to me too. IIRC I have commit access to the git repo, hence
I might commit this eventually (ping me in two weeks about this if
nobody else took care of this yet). However, before that happens I
think we should wait for more replies, maybe others have opinions
about this too, for example I am interested in Allison Lortie's
opinions on this (added to CC), I know she has some interest in the
basedir stuff, too.
Allison, any chance you can comment?

As I haven't been able to reach Lennart in the intervening months, is
there anyone else with commit access that could take a look at this?

[r***@gmail.com]

Post by Johannes Löthberg
The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

I didn't look at the patches (sorry), but I'll comment anyway--as long as it
is just standardizing ~/.local/bin as the *default* user-specific bin
directory, I have no objection.

But, I move all user specific configuration and similar files completely out of
~/ to a (non-standard named) top level directory, e.g., /<user>/local/bin.

And, in general, I keep those directories visible, not hidden.

[Lennart Poettering]

On Di, 29.08.17 18:42, Johannes Löthberg (***@kyriasis.com) wrote:

heya,

Post by Johannes Löthberg
I've had some old patches around for the XDG basedir spec, and figured I
might as well finally send them in and see what people think.
The first one just reformats some text and fixes some inconsistent
indentation, so should be pretty uncontroversial.
The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

Sorry for dropping the ball on this one.

The whole discussion just came up on fedora devel again, so I figured
I really should merge this now. I hence pinged Allison about this, one
of the original spec authors, and she suggested we should not define
any new env vars but simply document the dir as ~/.local/bin.

That made sense to me, and I have taken the liberty to change your
patches accordingly now, and dropped all references to any new env
var, I hope that's OK. I have however added a reference to UNIX $PATH,
and added that distros really should add ~/.local/bin to that path.

I have then posted the updated patch set here:

https://bugzilla.freedesktop.org/show_bug.cgi?id=106360

PTAL!

Maybe we'll get some more feedback if this is tracked in bugzilla
too. If not, I'll merge this like this in a day or two, but maybe
Allison beats me to it.

Anyway, sorry again for all the delays, let's get this settled, finally!

Lennart

[Josh Triplett]

Post by Lennart Poettering
heya,

Post by Johannes Löthberg
I've had some old patches around for the XDG basedir spec, and figured I
might as well finally send them in and see what people think.
The first one just reformats some text and fixes some inconsistent
indentation, so should be pretty uncontroversial.
The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

Sorry for dropping the ball on this one.
The whole discussion just came up on fedora devel again, so I figured
I really should merge this now. I hence pinged Allison about this, one
of the original spec authors, and she suggested we should not define
any new env vars but simply document the dir as ~/.local/bin.

While I don't think we need the full complexity of $XDG_BIN_DIRS, having
$XDG_BIN_HOME to override seems useful, for the same reason as the rest
of the $XDG_* variables. (With the full benefit of hindsight, I'd have
suggested having a single $XDG_HOME that defaults to ~/.local, serving as the root for
everything except $XDG_CONFIG_HOME, so that people could choose to point
it somewhere other than ~/.local without having to set a pile of
individual variables, but I don't think we can do anything
about that now. So given the current state, I think we should have an
$XDG_BIN_HOME analogous to the other $XDG_* variables to allow people to
point this elsewhere if they want. If they do, they'll have to take care
of getting it into $PATH and similar, but tools that install binaries
can use the desired directory as the target for installation.)

- Josh Triplett

[Lennart Poettering]

Post by Josh Triplett

Post by Lennart Poettering
heya,

Post by Johannes Löthberg
I've had some old patches around for the XDG basedir spec, and figured I
might as well finally send them in and see what people think.
The first one just reformats some text and fixes some inconsistent
indentation, so should be pretty uncontroversial.
The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

Sorry for dropping the ball on this one.
The whole discussion just came up on fedora devel again, so I figured
I really should merge this now. I hence pinged Allison about this, one
of the original spec authors, and she suggested we should not define
any new env vars but simply document the dir as ~/.local/bin.

While I don't think we need the full complexity of $XDG_BIN_DIRS, having
$XDG_BIN_HOME to override seems useful, for the same reason as the rest
of the $XDG_* variables. (With the full benefit of hindsight, I'd have
suggested having a single $XDG_HOME that defaults to ~/.local, serving as the root for
everything except $XDG_CONFIG_HOME, so that people could choose to point
it somewhere other than ~/.local without having to set a pile of
individual variables, but I don't think we can do anything
about that now. So given the current state, I think we should have an
$XDG_BIN_HOME analogous to the other $XDG_* variables to allow people to
point this elsewhere if they want. If they do, they'll have to take care
of getting it into $PATH and similar, but tools that install binaries
can use the desired directory as the target for installation.)

So yeah, Allison also suggested that having a single "XDG_PREFIX" env
var would have been the much better option, rather than have
individual ones. Now, that ship sailed pretty much, but that's not
reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
hardcoded as fallback prefix into the spec, so we should just accept
that here too, and admit that making this individually configurable
wasn't the best of ideas. I mean, making the searhc paths dynamically
configurable using an env var by all means made sense, but the "home"
dirs? i am not convinced...

But dunno, I am not feeling too strongly about this, but it appeared
to me that just not doing an env var here was the best way to get this
in quickly...

Lennart

[Josh Triplett]

Post by Lennart Poettering

Post by Josh Triplett

Post by Lennart Poettering
heya,

Post by Johannes Löthberg
I've had some old patches around for the XDG basedir spec, and figured I
might as well finally send them in and see what people think.
The first one just reformats some text and fixes some inconsistent
indentation, so should be pretty uncontroversial.
The second patch adds XDG_BIN_HOME and XDG_BIN_DIRS to the basedir spec,
standardizing ~/.local/bin as the default user-specific bin directory.

Sorry for dropping the ball on this one.
The whole discussion just came up on fedora devel again, so I figured
I really should merge this now. I hence pinged Allison about this, one
of the original spec authors, and she suggested we should not define
any new env vars but simply document the dir as ~/.local/bin.

While I don't think we need the full complexity of $XDG_BIN_DIRS, having
$XDG_BIN_HOME to override seems useful, for the same reason as the rest
of the $XDG_* variables. (With the full benefit of hindsight, I'd have
suggested having a single $XDG_HOME that defaults to ~/.local, serving as the root for
everything except $XDG_CONFIG_HOME, so that people could choose to point
it somewhere other than ~/.local without having to set a pile of
individual variables, but I don't think we can do anything
about that now. So given the current state, I think we should have an
$XDG_BIN_HOME analogous to the other $XDG_* variables to allow people to
point this elsewhere if they want. If they do, they'll have to take care
of getting it into $PATH and similar, but tools that install binaries
can use the desired directory as the target for installation.)

So yeah, Allison also suggested that having a single "XDG_PREFIX" env
var would have been the much better option, rather than have
individual ones. Now, that ship sailed pretty much, but that's not
reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
hardcoded as fallback prefix into the spec, so we should just accept
that here too, and admit that making this individually configurable
wasn't the best of ideas. I mean, making the searhc paths dynamically
configurable using an env var by all means made sense, but the "home"
dirs? i am not convinced...
But dunno, I am not feeling too strongly about this, but it appeared
to me that just not doing an env var here was the best way to get this
in quickly...

In the issue that originally motivated this, multiple people
specifically requested the ability to customize the target directory,
because their platform doesn't use ~/.local and wants to put that
somewhere else. This isn't a "maybe someone might use this someday",
this is "people specifically asked for this and intend to use it".

[Lennart Poettering]

Post by Josh Triplett

Post by Lennart Poettering
So yeah, Allison also suggested that having a single "XDG_PREFIX" env
var would have been the much better option, rather than have
individual ones. Now, that ship sailed pretty much, but that's not
reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
hardcoded as fallback prefix into the spec, so we should just accept
that here too, and admit that making this individually configurable
wasn't the best of ideas. I mean, making the searhc paths dynamically
configurable using an env var by all means made sense, but the "home"
dirs? i am not convinced...
But dunno, I am not feeling too strongly about this, but it appeared
to me that just not doing an env var here was the best way to get this
in quickly...

In the issue that originally motivated this, multiple people
specifically requested the ability to customize the target directory,
because their platform doesn't use ~/.local and wants to put that
somewhere else. This isn't a "maybe someone might use this someday",
this is "people specifically asked for this and intend to use it".

Well, it's fine if people use different install prefixes. The question
though is if the xdg basedir spec really needs to care too much about
that. I mean, what matters really is that the XDG basedir spec defines
*search* paths env vars where we previously had none. The *home* paths
otoh are a different story, for them the extra configurability is
entirely unnecessary as I see it, as your app can drop stuff wherever
you want as long as there's a way to register that in the various
search paths. And when you place the stuff at arbitrary places, then
you probably should configure that through a prefix, not through the
individual home dirs of each individual concept...

Hence, I think it's a good thing if the spec defines *search* paths
for everything where we have none before, i.e. to augment UNIX' $PATH,
and Linux' $LD_LIBRARY_PATH and suchlike. I also think it's a good
thing if the spec declares that ~/.local/<something> is a great place
to place stuff, if you are looking for a good place to put something
and didn't get told anything more specific. I also think it's a good
thing if the spec delcares that ~/.local/bin should appear in
$PATH. However, I really don't see the benefit of adding individual
configurability for each of the home dirs, because you should already
have that anyway though the prefix dir you use when configuring your
package...

Lennart

[Josh Triplett]

Post by Lennart Poettering
Well, it's fine if people use different install prefixes. The question
though is if the xdg basedir spec really needs to care too much about
that. I mean, what matters really is that the XDG basedir spec defines
*search* paths env vars where we previously had none. The *home* paths
otoh are a different story, for them the extra configurability is
entirely unnecessary as I see it, as your app can drop stuff wherever
you want as long as there's a way to register that in the various
search paths. And when you place the stuff at arbitrary places, then
you probably should configure that through a prefix, not through the
individual home dirs of each individual concept...

I don't have any objection to configuring this via an $XDG_PREFIX
instead, defaulting to ~/.local, and then saying the binary directory is
$XDG_PREFIX/bin.

Post by Lennart Poettering
However, I really don't see the benefit of adding individual
configurability for each of the home dirs, because you should already
have that anyway though the prefix dir you use when configuring your
package...

This would provide a standardized way to *configure* that prefix,
because not all the world's a ./configure --prefix. The motivating use
case for this, for instance, was Rust's Cargo package manager, which
would like to have a sensible default for where `cargo install` should
install binaries.

[Simon McVittie]

Post by Josh Triplett

Post by Lennart Poettering
However, I really don't see the benefit of adding individual
configurability for each of the home dirs, because you should already
have that anyway though the prefix dir you use when configuring your
package...

This would provide a standardized way to *configure* that prefix,
because not all the world's a ./configure --prefix. The motivating use
case for this, for instance, was Rust's Cargo package manager, which
would like to have a sensible default for where `cargo install` should
install binaries.

Does `cargo install` have an equivalent of Autoconf --prefix, CMake
CMAKE_INSTALL_PREFIX and Meson --prefix? If not, it should, and it can
without freedesktop.org needing to standardize anything.

Other build systems like Autoconf, CMake and Meson don't default to
installing in a per-user location. Should cargo really be different?

I don't think the developers of Autoconf, CMake and Meson are going to
change their default prefix from /usr/local to some sort of XDG_PREFIX
any time soon...

smcv

[e***@markus-raab.org]

Hi,

I agree with Lennart it is not a good choice to just throw env vars onto
everything. But I disagree that "best way to get this in quickly..." is
something we should use as argument.

About the patch:
"at an appropriate place" does not add anything useful, remove it or
suggest something concrete.

Post by Josh Triplett
This isn't a "maybe someone might use this someday",
this is "people specifically asked for this and intend to use it".

Please cite. I would be interested who the people are and what they want
to do with it.

I don't have any objection to configuring this via an $XDG_PREFIX

Post by Josh Triplett
instead, defaulting to ~/.local, and then saying the binary directory is
$XDG_PREFIX/bin.

I would not make this configurable, unless there is a good use case for
it. The search path (PATH) is the relevant place. Having multiple places
to configure the same path only brings inconsistencies.

If you want such a prefix nevertheless, XDG_LOCAL might be a better
name. Imho the name XDG_PREFIX is too generic.

Post by Josh Triplett

Post by Lennart Poettering
However, I really don't see the benefit of adding individual
configurability for each of the home dirs, because you should already
have that anyway though the prefix dir you use when configuring your
package...

This would provide a standardized way to *configure* that prefix,
because not all the world's a ./configure --prefix.

XDG_LOCAL or XDG_BIN_DIRS would not help here at all. If the software
does not support --prefix it won't support XDG_LOCAL or XDG_BIN_DIRS.
PATH does help here.

The argument for XDG_LOCAL or XDG_BIN_DIRS would be that these env vars
could be used to drop binaries to. But, as I understand it, it is not
the responsibility of XDG to provide build/install configuration.

best regards,

[Lennart Poettering]

Post by Lennart Poettering
So yeah, Allison also suggested that having a single "XDG_PREFIX" env
var would have been the much better option, rather than have
individual ones. Now, that ship sailed pretty much, but that's not
reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
hardcoded as fallback prefix into the spec, so we should just accept
that here too, and admit that making this individually configurable
wasn't the best of ideas. I mean, making the searhc paths dynamically
configurable using an env var by all means made sense, but the "home"
dirs? i am not convinced...
But dunno, I am not feeling too strongly about this, but it appeared
to me that just not doing an env var here was the best way to get this
in quickly...

So here's a strong reason for not having XDG_BIN_HOME: because $PATH
is not designed to refer to other env vars, it expects literal
paths. After all, for XDG_DATA_DIRS (and similar for the other search
path env vars) the basedir spec says that you need to search in both
XDG_DATA_DIRS and XDG_DATA_HOME, i.e. both variables are independent
of each other. But this is not how $PATH works: the variable is
implemented and respected all over the place, but what isn't listed in
it doesn't matter, hence we can define XDG_BIN_HOME as much as we
want, nobody would care, it would never be consulted.

Something similar applies to ~/.local/lib64/ and friends btw, if
people want that. For shared libraries too there's already a search
path variable defined, in LD_LIBRARY_PATH, and that too doesn't care
about XDG_LIB_HOME. Hence defining XDG_LIB_HOME doesn't make much
sense either...

Hence let's no introduce env vars that can't be supported anyway
please.

Lennart

[Josh Triplett]

Post by Lennart Poettering

Post by Lennart Poettering
So yeah, Allison also suggested that having a single "XDG_PREFIX" env
var would have been the much better option, rather than have
individual ones. Now, that ship sailed pretty much, but that's not
reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
hardcoded as fallback prefix into the spec, so we should just accept
that here too, and admit that making this individually configurable
wasn't the best of ideas. I mean, making the searhc paths dynamically
configurable using an env var by all means made sense, but the "home"
dirs? i am not convinced...
But dunno, I am not feeling too strongly about this, but it appeared
to me that just not doing an env var here was the best way to get this
in quickly...

So here's a strong reason for not having XDG_BIN_HOME: because $PATH
is not designed to refer to other env vars, it expects literal
paths. After all, for XDG_DATA_DIRS (and similar for the other search
path env vars) the basedir spec says that you need to search in both
XDG_DATA_DIRS and XDG_DATA_HOME, i.e. both variables are independent
of each other. But this is not how $PATH works: the variable is
implemented and respected all over the place, but what isn't listed in
it doesn't matter, hence we can define XDG_BIN_HOME as much as we
want, nobody would care, it would never be consulted.

Tools that install binaries can and should consult it, and I'd like to
see those tools not hardcoding ~/.local/bin.

If someone sets $XDG_BIN_HOME, it'll be their responsibility to put the
target directory in $PATH. A distribution could, by default, add
~/.local/bin to $PATH in /etc/skel/.bashrc, and if someone wants to set
$XDG_BIN_HOME they can edit their own ~/.bashrc to do so. And for that
matter, if the distribution itself wants to set $XDG_BIN_HOME they'll
also set $PATH accordingly.

- Josh Triplett

[Simon McVittie]

Post by Josh Triplett
With the full benefit of hindsight, I'd have
suggested having a single $XDG_HOME that defaults to ~/.local, serving as the root for
everything except $XDG_CONFIG_HOME, so that people could choose to point
it somewhere other than ~/.local without having to set a pile of
individual variables

As you noted, XDG_CONFIG_HOME doesn't/shouldn't go in ~/.local, and
XDG_CACHE_HOME doesn't/shouldn't go in ~/.local either, so actually
that pile of individual variables is just XDG_DATA_HOME and the proposed
XDG_BIN_HOME, and possibly XDG_LIB_HOME if someone really wants it
in future.

What is this variable for? Is it for applications that write out data, or
is it just as a default for build systems that want to install "packages"
into the home directory?

I suspect only the latter, so maybe XDG_PREFIX or XDG_LOCAL_INSTALL
or something would make more sense? (With the caveat that if you set
XDG_DATA_HOME and XDG_PREFIX in contradictory ways, finding just-installed
.desktop, .service etc. files won't work as intended - but the same is
true of PATH and your proposed XDG_BIN_HOME, or LD_LIBRARY_PATH and a
hypothetical XDG_LIB_HOME, already.)

smcv