[2 Eddy_Em] [FHS] Насчет /opt

А не так то, что лучше бы они по-человечески, в /usr/bin, /usr/lib и т.п. свои файлы распихивали.

Если бы не было opt, нельзя было бы поставить нужную версию приложения в нужное место на ФС. У мну даже в хомяке есть свой ~/opt

>/usr/bin, /usr/lib

Эти директории для файлов дистрибутивных пакетов. Сторонние всегда в /opt ставили. Насколько я помню, это в стандарте прописано

>stevejobs

У мну даже в хомяке есть свой ~/opt

~/Applications ??

Ну, мне такая мусорка не нравится. И не нравится, что из-за некоторых нехороших разработчиков приходится вручную делать симлинки в /usr/bin и /usr/lib на установленный в /opt софт.

> ~/Applications ??

за исключением того, что это линух - используются примерно с такой же сутью.
А еще туда можно конпелять configure --prefix=$HOME/opt/application_name && make && make install. Получается расово верная структура. Надо бы еще скриптов для нее навелосипедить для ldconfig и прочего, да никак руки не дойдут..

> Ну, мне такая мусорка не нравится. И не нравится, что из-за некоторых нехороших разработчиков приходится вручную делать симлинки в /usr/bin и /usr/lib на установленный в /opt софт.

Как бы то ни было, а в стандарте есть. Так что отсылка к FHS на аргумент не тянет.

> конпелять configure --prefix=$HOME/opt/application_name && make && make install. Получается расово верная структура

Собственно, так и собираю софт, над которым работаю, c --prefix=$HOME/builds/blabla

PATH отменили? зачем засорять /usr/bin левыми симлинками?

>А не так то, что лучше бы они по-человечески, в /usr/bin, /usr/lib и т.п. свои файлы распихивали.
По-моему, они как раз FHS читали и используют /opt правильно: http://www.pathname.com/fhs/2.2/fhs-3.12.html

Или ты хочешь себе DLL-Hell .so-hell и bin-hell в своей системе?

> .so-hell и bin-hell

Если файлы под контролем пакетника, никакого hell.

(ой, да, для педантов обновленная ссылка:http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES)

>Если файлы под контролем пакетника, никакого hell.
Пакетник решит проблему только в случае конфликта пакетов и только одним способом: «Не буду ставить. Оно файлы перезаписывать хочет.»

Во всех более сложных случаях проблема останется: у тебя в системе будет сидеть то, что должно быть засунуто в отдельную песочницу.

но Eddy_Em разводит себе *hell симлинками, про это собсно и речь :)

> Во всех более сложных случаях проблема останется: у тебя в системе будет сидеть то, что должно быть засунуто в отдельную песочницу.

Ну с этой точки зрения, да.

И что, я буду в PATH писать /opt/*/*/* ? И сколько времени баш будет искать команду?

Ты работаешь на первопне?

>И сколько времени баш будет искать команду?
Пользователи GoboLinux'а по 100500 путей туда вносят и, по их словам, не замечают большого замедления, а у тебя 5 путей, судя по процитированному сообщению, будет.

Если у тебя в /opt не больше десятка софтин, как обычно бывает, то будет искать также как если бы у тебя не было никакого /opt'а.

man update-alternatives

P.S. ну я не спорю что это disto-specific :)

> Пользователи GoboLinux'а по 100500 путей туда вносят

Ты что-то путаешь. В GoboLinux симлинки, которыми рулит пакетник.

>Ты что-то путаешь. В GoboLinux симлинки, которыми рулит пакетник.
Мне казалось, что это вспомогательный механизм и рулит не пакетник, а патч в ядре. Впрочем, не знаю точно. Все равно ведь надо ждать 015. :)

Патч в ядре рулит только скрытием стандартных FHSных каталогов, в которых и лежат симлинки.

> патч в ядре

Патч в ядре нужен только чтобы скрыть «тысячи их» лишние элементы корневого каталога. Потому что религия разработчиков Gobo в том, что все системные пути файлов Должны Начинаться С Большой Буквы.

К организации пакетного менеджера этот косметический патч отношения не имеет. С тем же успехом, его на дебиан присадить можно, например.

Вот оно как. Ясно.