В чем разница между /opt и /usr /local?

Хотя оба предназначены для хранения файлов, не принадлежащих к операционной системе, /opt и /usr/local не должны содержать один и тот же набор файлов.

/usr/local - это место для установки файлов, созданных администратором, обычно с помощью команды make (например, ./configure; make; make install). Идея состоит в том, чтобы избежать столкновений с файлами, которые являются частью операционной системы, которые будут либо перезаписаны, либо перезаписаны локальными в противном случае (например, /usr/bin/foo является частью ОС в то время как /usr /local /bin /foo является локальной альтернативой).

Все файлы в разделе /usr/local/bin/foo являются общими для экземпляров ОС, хотя это редко делается с Linux. Это часть, в которой FHS слегка противоречит друг другу, поскольку /usr определяется как доступный только для чтения, но /usr пишите для локальной установки программного обеспечения для успеха. Стандарт файловой системы SVR4, который был основным источником вдохновения FHS, рекомендует избегать /usr/local/bin и использовать /usr/local для решения этой проблемы.

/opt/local является наследием исходного BSD. В то время исходный код OS-команд /usr/local находился в /usr/bin и /usr/src/bin, а источник локально разработанных команд находился в /usr/src/usr.bin и их двоичные файлы в /usr/local/src. Не было понятия упаковки (вне tarballs).

С другой стороны, /usr/local/bin - это каталог для установки разделенных пакетов (т. е. пакетов, не входящих в дистрибутив операционной системы, но предоставляемых независимым источником), каждый из которых находится в своем собственном подкаталоге. Они уже создали целые пакеты, предоставляемые независимым сторонним дистрибьютором программного обеспечения. В отличие от /opt, эти пакеты соответствуют соглашениям с каталогами (или, по крайней мере, они должны). Например, /usr/local будет установлен в someapp, при этом одна из его команд будет /opt/someapp, ее файл конфигурации будет находиться в /opt/someapp/bin/foo и его файлы журнала в /etc/opt/someapp/foo.conf.

Основное отличие состоит в том, что /usr/local предназначен для программного обеспечения, которое не управляется системным пакетом, но все еще соответствует стандартным правилам развертывания unix.

Вот почему у вас есть /usr/local/bin, /usr/local/sbin /usr/local/include и т. д. .

/opt, с другой стороны, предназначен для программного обеспечения, которое не следует этому и развертывается монолитно. Это обычно включает коммерческое и /или кросс-платформенное программное обеспечение, которое упаковано в стиле «Windows».

Они очень похожи, и использование того или другого - это скорее вопрос. Журнал Linux имел эту точку /контрапунктную дискуссию об этой точной теме здесь .

Во-первых, я не думаю, что существует строгий ответ; другой у администраторов будут разные мнения, согласно их задний план. Исторически сложилось, что /usr/local пришел первым; это было конвенции в Беркли, IIRC. В какой-то момент во время развитие Системы V, если я не ошибаюсь (это все длинное назад, и я не делал заметок), было решение или желание иметь возможность монтировать /usr только для чтения, что означало, что вы не мог добавить к нему новое программное обеспечение; возможно, поэтому /opt было изобретено. Как это бывает, было так много программное обеспечение, которое записывало в /usr, что эта идея никогда не была сошел с земли.

Мои личные предпочтения - /opt, с отдельным подкаталогом для каждого продукта; это делает удаление продукта простым случаем rm -fr. Но если все ваше программное обеспечение установлено через хороший менеджер пакетов, это не имеет значения, и если программное обеспечение вы install не строго подчиняется этим соглашениям и пишет конфигурации и т. д. в /usr, это не либо по разным причинам.

Для меня лично, это то, что Билл сказал по ссылке @ philfr:

  

В системе разработки или в песочнице, имеющей каталог /opt, где вы можете просто бросить вещи и посмотреть, работают ли они, имеет много смысла. Я знаю, что я не собираюсь прилагать усилия, чтобы самим упаковать вещи, чтобы попробовать их. Если приложение не работает, вы можете просто rm каталог /opt /mytestapp, и это приложение является историей. Упаковка может иметь смысл, когда вы запускаете большое развертывание (иногда я делаю пакетные приложения), но много раз, приятно вставлять вещи в /opt.

К сожалению, большинство сценариев make install выталкивают файлы в /usr/local, а не просто создают символическую ссылку: - /

У меня немного другое отношение к этой проблеме.
Хотя все в jlliagre , практическое приложение для меня при развертывании программного обеспечения в кластере сводится к переменным окружения по умолчанию и повторному использованию libs по умолчанию.

Проще говоря - /usr/local, и все его дочерние dir находятся в соответствующих env vars, таких как PATH и MANPATH и /usr /local /lib {, 64} находятся в файле ldconfig (/usr/local/lib{,64}).

/etc/ld.so.conf.d/ OTOH не является преимуществом, когда требуется, чтобы несколько версий или конфликтующие пакеты сосуществовали в системе, но требует какого-то управления средой (например, среды-модули или ), и невыгодно в том, что он потенциально может« отбросить »пространство для хранения путем дублирования разделяемых библиотек, поскольку каждая установка в /opt/ может быть полностью автономной.

Для совместной работы /opt, предполагается, что, например, двоичные файлы устанавливаются непосредственно в /usr/local (и справочные страницы для соответствующего /usr/local/bin), а не /usr/local/share/man/... и т. д.