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

В соответствии со стандартом иерархии файловых/opt систем , предназначен для «установки дополнительных программных пакетов приложений». /usr/local"для использования системным администратором при локальной установке программного обеспечения". Эти варианты использования кажутся довольно похожими. Программное обеспечение, не включенное в дистрибутивы, обычно настроено по умолчанию для установки в одном /usr/localили /optбез конкретной рифмы или причины, по которой они выбрали.

Есть ли какая-то разница, по которой я скучаю, или оба делают одно и то же, но существуют по историческим причинам?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня немного другое мнение по этому вопросу.
В то время как все в jlliagre «s ответ является правильным, практическое применение для меня, при развертывании программного обеспечения в кластере, сводится к переменным окружения по умолчанию и повторное использование LIBS по умолчанию.

Проще говоря - /usr/localи все его дочерние каталоги находятся в соответствующих переменных env, таких как PATHи MANPATH, и /usr/local/lib{,64}в ldconfig ( /etc/ld.so.conf.d/).

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

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