В чем разница между /opt и /usr /local?
Согласно стандарту иерархии файловой системы , /opt
для «установки дополнительных программных пакетов приложений». /usr/local
является «для использования системным администратором при локальном установке программного обеспечения». Эти варианты использования выглядят довольно похожими. Программное обеспечение, не входящее в дистрибутивы, обычно настраивается по умолчанию для установки в /usr/local
или /opt
без особых рифм или причин, по которым они выбрали.
Есть ли какая-то разница, которую мне не хватает, или делают то же самое, но существуют по историческим причинам?
6 ответов
Хотя оба предназначены для хранения файлов, не принадлежащих к операционной системе, /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».
Во-первых, я не думаю, что существует строгий ответ; другой
у администраторов будут разные мнения, согласно их
задний план. Исторически сложилось, что /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/...
и т. д.