История изменений

А причина на самом деле вот какая. Само ~/.local планировалось как юзерский аналог /usr (оттуда и bin/lib). Но вот какое дело, /usr/share это место для хранения, в том числе, дефолтных конфигов, а место для хранения настроенных конфигов - /etc (которому аналог ~/.config). В контексте системы разделение понятно - дефолтные конфиги ставит пакетный менеджер, а настроенные - могут редактироваться администратором. В контексте юзера это разделение выглядит сомнительно - дефолты всё так же хранятся в /usr/share, дублировать их в ~/.local/share незачем. Остаётся одно единственное вменяемое применение: класть в ~/.local/share дефолты софта, установленного самим юзером себе в $HOME с префиксом $HOME/.local (например, через ./configure --prefix=$HOME/.local && make install). Собственно, ~/.local/bin и ~/.local/lib аналогично. То, что туда что-то пишут проги про запуске (не инсталляторы) - некорректное поведение. То, что установленные общесистемно проги оттуда что-то читают - ну, наверно допустимо (хотя я не уверен), но только если юзер сам решил таким образом подменить /usr/share. То есть, дефолтно никакого ~/.local/share существовать не должно, он может появиться только при явном на то желании юзера.

Если бы он существовал именно в таком виде - я бы его не осуждал, более того у меня было ~/usr/ для аналогичной цели когда-то (распаковывал туда deb-пакеты), а сейчас есть ~/DEV/{lib|include|man|src}/ для локальной компиляции при разработке.

Программы, установленные системным пакетным менеджером, вполне могли бы обойтись двумя директориями, какими-нить ~/.state/NAME и ~/.cache/NAME, причём большинству - только первая. И незачем делать всякие $XDG_XXX_DIR, это только добавляет лишнюю логику в куче мест системы, вполне нормально обращаться к ним через $HOME. Тогда можно точно знать, что вот есть максимум два места, где можно искать автосозданные прогой файлы. А кому надо другое место - есть симлинки.

Впрочем, некоторые я бы всё равно оставил в корне например ~/.ssh.

А причина на самом деле вот какая. Само ~/.local планировалось как юзерский аналог /usr (оттуда и bin/lib). Но вот какое дело, /usr/share это место для хранения, в том числе, дефолтных конфигов, а место для хранения настроенных конфигов - /etc (которому аналог ~/.config). В контексте системы разделение понятно - дефолтные конфиги ставит пакетный менеджер, а настроенные - могут редактироваться администратором. В контексте юзера это разделение выглядит сомнительно - дефолты всё так же хранятся в /usr/share, дублировать их в ~/.local/share незачем. Остаётся одно единственное вменяемое применение: класть в ~/.local/share дефолты софта, установленного самим юзером себе в $HOME с префиксом $HOME/.local (например, через ./configure --prefix=$HOME/.local && make install). Собственно, ~/.local/bin и ~/.local/lib аналогично. То, что туда что-то пишут проги про запуске (не инсталляторы) - некорректное поведение. То, что установленные общесистемно проги оттуда что-то читают - ну, наверно допустимо (хотя я не уверен), но только если юзер сам решил таким образом подменить /usr/share. То есть, дефолтно никакого ~/.local/share существовать не должно, он может появиться только при явном на то желании юзера.

Если бы он существовал именно в таком виде - я бы его не осуждал, более того у меня было ~/usr/ для аналогичной цели когда-то (распаковывал туда deb-пакеты), а сейчас есть ~/DEV/{lib|include|man|src}/ для локальной компиляции при разработке.

Программы, установленные системным пакетным менеджером, вполне могли бы обойтись двумя директориями, какими-нить ~/.state/NAME и ~/.cache/NAME, причём большинству - только первая. И незачем делать всякие $XDG_XXX_DIR, это только добавляет лишнюю логику в куче мест системы, вполне нормально обращаться к ним через $HOME. Тогда можно точно знать, что вот есть максимум два места, где можно искать автосозданные прогой файлы. А кому надо другое место - есть симлинки.

Впрочем, некоторые я бы всё равно оставил в корне например ~/.ssh.

А причина на самом деле вот какая. Само ~/.local планировалось как юзерский аналог /usr (оттуда и bin/lib). Но вот какое дело, /usr/share это место для хранения, в том числе, дефолтных конфигов, а место для хранения настроенных конфигов - /etc (которому аналог ~/.config). В контексте системы разделение понятно - дефолтные конфиги ставит пакетный менеджер, а настроенные - могут редактироваться администратором. В контексте юзера это разделение выглядит сомнительно - дефолты всё так же хранятся в /usr/share, дублировать их в ~/.local/share незачем. Остаётся одно единственное вменяемое применение: класть в ~/.local/share дефолты софта, установленного самим юзером себе в $HOME с префиксом $HOME/.local (например, через ./configure --prefix=$HOME/.local && make install). Собственно, ~/.local/bin и ~/.local/lib аналогично. То, что туда что-то пишут проги про запуске (не инсталляторы) - некорректное поведение. То, что установленные общесистемно проги оттуда что-то читают - ну, наверно допустимо (хотя я не уверен), но только если юзер сам решил таким образом подменить /usr/share. То есть, дефолтно никакого ~/.local/share существовать не должно, он может появиться только при явном на то желании юзера.

Если бы он существовал именно в таком виде - я бы его не осуждал, более того у меня было ~/usr/ для аналогичной цели когда-то (распаковывал туда deb-пакеты), а сейчас есть ~/DEV/{lib|include|man|src}/ для локальной компиляции при разработке.

Программы, установленные системным пакетным менеджером, вполне могли бы обойтись двумя директориями, какими-нить ~/.state/NAME и ~/.cache/NAME, причём большинству - только первая. И незачем делать всякие $XDG_XXX_DIR, это только добавляет лишнюю логику в куче мест системы, вполне нормально обращаться к ним через $HOME. Тогда можно точно знать, что вот есть максимум два места, где можно искать автосозданные прогой файлы. А кому надо другое место - есть симлинки.

Впрочем, некоторые я бы всё равно оставил в корне например ~/.ssh.

А причина на самом деле вот какая. Само ~/.local планировалось как юзерский аналог /usr (оттуда и bin/lib). Но вот какое дело, /usr/share это место для хранения, в том числе, дефолтных конфигов, а место для хранения настроенных конфигов - /etc (которому аналог ~/.config). В контексте системы разделение понятно - дефолтные конфиги ставит пакетный менеджер, а настроенные - могут редактироваться администратором. В контексте юзера это разделение выглядит сомнительно - дефолты всё так же хранятся в /usr/share, дублировать их в ~/.local/share незачем. Остаётся одно единственное вменяемое применение: класть в ~/.local/share дефолты софта, установленного самим юзером себе в $HOME с префиксом $HOME/.local (например, через ./configure --prefix=$HOME/.local && make install). Собственно, ~/.local/bin и ~/.local/lib аналогично. То, что туда что-то пишут проги про запуске (не инсталляторы) - некорректное поведение. То, что установленные общесистемно проги оттуда что-то читают - ну, наверно допустимо (хотя я не уверен), но только если юзер сам решил таким образом подменить /usr/share. То есть, дефолтно никакого ~/.local/share существовать не должно, он может появиться только при явном на то желании юзера.

Если бы он существовал именно в таком виде - я бы его не осуждал, более того у меня было ~/usr/ для аналогичной цели когда-то (распаковывал туда deb-пакеты), а сейчас есть ~/DEV/{lib|include|man|src}/ для локальной компиляции при разработке.

Программы, установленные системным пакетным менеджером, вполне могли бы обойтись двумя директориями, какими-нить ~/.state/NAME и ~/.cache/NAME, причём большинству - только первая. И незачем делать всякие $XDG_XXX_DIR, это только добавляет лишнюю логику в куче мест системы, вполне нормально обращаться к ним через $HOME. Тогда можно точно знать, что вот есть максимум два места, где можно искать автосозданные прогой файлы. А кому надо другое место - есть симлинки.

Впрочем, некоторые я бы всё равно оставил в корне например ~/.ssh .

А причина на самом деле вот какая. Само ~/.local планировалось как юзерский аналог /usr (оттуда и bin/lib). Но вот какое дело, /usr/share это место для хранения, в том числе, дефолтных конфигов, а место для хранения настроенных конфигов - /etc (которому аналог ~/.config). В контексте системы разделение понятно - дефолтные конфиги ставит пакетный менеджер, а настроенные - могут редактироваться администратором. В контексте юзера это разделение выглядит сомнительно - дефолты всё так же хранятся в /usr/share, дублировать их в ~/.local/share незачем. Остаётся одно единственное вменяемое применение: класть в ~/.local/share дефолты софта, установленного самим юзером себе в $HOME с префиксом $HOME/.local (например, через ./configure --prefix=$HOME/.local && make install). Собственно, ~/.local/bin и ~/.local/lib аналогично. То, что туда что-то пишут проги про запуске (не инсталляторы) - некорректное поведение. То, что установленные общесистемно проги оттуда что-то читают - ну, наверно допустимо (хотя я не уверен), но только если юзер сам решил таким образом подменить /usr/share. То есть, дефолтно никакого ~/.local/share существовать не должно, он может появиться только при явном на то желании юзера.

Если бы он существовал именно в таком виде - я бы его не осуждал, более того у меня было ~/usr/ для аналогичной цели когда-то (распаковывал туда deb-пакеты), а сейчас есть ~/DEV/{lib|include|man|src}/ для локальной компиляции при разработке.

Программы, установленные системным пакетным менеджером, вполне могли бы обойтись двумя директориями, какими-нить ~/.state/NAME и ~/.cache/NAME, причём большинству - только первая. И незачем делать всякие $XDG_XXX_DIR, это только добавляет лишнюю логику в куче мест системы, вполне нормально обращаться к ним через $HOME. Тогда можно точно знать, что вот есть максимум два места, где можно искать автосозданные прогой файлы.

Впрочем, некоторые я бы всё равно оставил в корне например ~/.ssh .