В чем разница между / 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 OS находился в /usr/src/bin и /usr/src/usr.bin , а источник локально разработанных команд был в /usr/local/src , а их двоичные файлы в /usr/local/bin . Не было понятия упаковки (за пределами tarballs).

С другой стороны, /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 имел эту точку / контрапунктную дискуссию об этой точной теме.

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

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

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

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

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

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

Проще говоря – /usr/local и все его дочерние директории находятся в соответствующих env vars, таких как 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,...} и т. д.