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

<p>в соответствии с <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html">стандарт иерархии файловой системы</a> , <code>/opt</code> для "установки дополнительных программных пакетов приложений". <code>/usr/local</code> "для использования системным администратором при локальной установке программного обеспечения". эти варианты использования кажутся довольно похожими. программное обеспечение, не включенное в дистрибутивы, обычно по умолчанию настроено для установки в <code>/usr/local</code> или <code>/opt</code> без конкретной рифмы или причины, по которой они выбрали.</p><p>есть ли какая-то разница, по которой я скучаю, или оба делают одно и то же, но существуют по историческим причинам?</p>

<p>хотя оба предназначены для хранения файлов, не принадлежащих операционной системе, <code>/opt</code> а также <code>/usr/local</code> не должны содержать одинаковый набор файлов.</p><p><code>/usr/local</code> - это место для установки файлов, созданных администратором, обычно с помощью команды <code>make</code> (например, <code>./configure; make; make install</code>). идея состоит в том, чтобы избежать конфликтов с файлами, которые являются частью операционной системы, которые могут быть перезаписаны или перезаписаны локальными (в противном случае <code>/usr/bin/foo</code> является частью ос, а <code>/usr/local/bin/foo</code> является местной альтернативой).</p><p>все файлы в <code>/usr</code> делятся между экземплярами ос, хотя это редко делается в linux. это часть, где fhs немного противоречив, как <code>/usr</code> определено как доступное только для чтения, но <code>/usr/local/bin</code> для успешной локальной установки программного обеспечения необходимо чтение и запись. стандарт файловой системы svr4, который был основным источником вдохновения fhs, рекомендует избегать <code>/usr/local</code> и используйте <code>/opt/local</code> вместо этого, чтобы преодолеть эту проблему.</p><p><code>/usr/local</code> является наследием от оригинального bsd. в то время исходный код <code>/usr/bin</code> команды ос были в <code>/usr/src/bin</code> а также <code>/usr/src/usr.bin</code>, в то время как источник локально разработанных команд находился в <code>/usr/local/src</code> и их двоичные файлы в <code>/usr/local/bin</code>. там не было никакого понятия упаковки (вне тарболы).</p><p>с другой стороны, <code>/opt</code> - это каталог для установки разделенных пакетов (то есть пакетов, не входящих в дистрибутив операционной системы, но предоставленных независимым источником), каждый из которых находится в своем собственном подкаталоге. они уже созданы целыми пакетами, предоставленными независимым сторонним дистрибьютором программного обеспечения. в отличие от <code>/usr/local</code> вещи, эти пакеты следуют соглашениям каталога (или, по крайней мере, они должны). например, <code>someapp</code> будет установлено в <code>/opt/someapp</code>, одной из команд которой является <code>/opt/someapp/bin/foo</code>, его файл конфигурации будет находиться в <code>/etc/opt/someapp/foo.conf</code> и его файлы журналов в <code>/var/opt/someapp/logs/foo.access</code>.</p>

<p>основное отличие состоит в том, что <code>/usr/local</code> предназначено для программного обеспечения, которое не управляется системным упаковщиком, но все еще следует стандартным правилам развертывания unix.</p><p>вот почему у вас есть <code>/usr/local/bin</code>, <code>/usr/local/sbin</code> <code>/usr/local/include</code> и т. д ...</p><p><code>/opt</code> с другой стороны, для программного обеспечения, которое не следует этому и развернуто монолитным способом. обычно это коммерческое и/или кроссплатформенное программное обеспечение, упакованное в стиле "windows".</p>

<p>они на самом деле очень похожи, и использование того или другого - это вопрос мнения. журнал linux обсуждал эту тему/контрапункт именно по этой теме <a href="http://www.linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal">здесь</a> .</p>

<p>лично для меня это то, что билл сказал в ссылке @ philfr:</p><blockquote> <p>в системе разработки или в песочнице наличие каталога/opt, в котором вы можете просто бросить вещи и посмотреть, работают ли они, имеет большой смысл. я знаю, что я не собираюсь самостоятельно собирать вещи, чтобы попробовать их. если приложение не работает, вы можете просто запустить каталог/opt/mytestapp, и это приложение станет историей. упаковка может иметь смысл, когда вы запускаете большое развертывание (бывают случаи, когда я создаю пакетные приложения), но во многих случаях приятно бросать вещи в/opt.</p> </blockquote><p>к сожалению, большинство <code>make install</code> скрипты помещают файлы в <code>/usr/local</code> вместо того, чтобы просто сделать символическую ссылку там: - /</p>

<p>во-первых, я не думаю, что есть строгий ответ; разные администраторы будут иметь разные мнения, в зависимости от их происхождения. исторически, <code>/usr/local</code> пришел первым; это была конвенция в беркли, iirc. в какой-то момент во время разработки system v, если я не ошибаюсь (это все давно, и я не делал заметок), было решение или желание иметь возможность смонтировать <code>/usr</code> только для чтения, что означало, что вы не можете добавлять в него новое программное обеспечение; возможно, именно поэтому <code>/opt</code> было изобретено. так получилось, что существовало так много программного обеспечения, которое писало в <code>/usr</code> что эта идея так и не началась.</p><p>мое личное предпочтение <code>/opt</code>, с отдельным подкаталогом для каждого продукта; это делает удаление продукта простым случаем <code>rm -fr</code>. но если все ваше программное обеспечение установлено через хороший менеджер пакетов, это не имеет значения, и если программное обеспечение, которое вы устанавливаете, не подчиняется строго этим соглашениям и записывает конфигурации и тому подобное где-то в <code>/usr</code>, это тоже не имеет значения, хотя по противоположным причинам.</p>

<p>у меня немного другое мнение по этому вопросу.<br> хотя все в <a href="https://unix.stackexchange.com/users/2594/jlliagre">jlliagre</a> s <a href="https://unix.stackexchange.com/a/11552/77319">answer</a> верно, практическое применение для меня при развертывании программного обеспечения в кластере сводится к переменным среды по умолчанию и по умолчанию повторное использование библиотек.</p><p>проще говоря - <code>/usr/local</code> и все его дочерние каталоги находятся в соответствующих переменных env, таких как <code>path</code> и <code>manpath</code>, <code>/usr/local/lib{,64}</code> находятся в ldconfig (<code>/etc/ld.so.conf.d/</code>).</p><p><code>/opt/</code> otoh нет - что выгодно, когда требуется сосуществование нескольких версий или конфликтующих пакетов в системе, но требует некоторого вида управления средой (например, <a href="http://modules.sourceforge.net">environment-modules</a> или <a href="https://www.softwarecollections.org/en/">наборы программного обеспечения</a> ), и его недостаток в том, что он потенциально "тратит" пространство памяти, дублируя общие библиотеки, как каждая установка в <code>/opt</code> может быть полностью автономным.</p><p>для общей природы <code>/usr/local</code> для работы предполагается, что, например, двоичные файлы устанавливаются непосредственно в <code>/usr/local/bin</code> (и справочные страницы, чтобы присвоить <code>/usr/local/share/man/...</code>) скорее, чем <code>/usr/local/app/{bin,share/man,...}</code> так далее.</p>

<h2>таким образом, мой внутренний ответ ...</h2><p>используя мою справедливую долю freebsd с 2.2.6 и red hat linux с версии 9 ...</p><pre><code>/usr/local == old school conventions /opt == new school conventions </code></pre><p>расположение вещей в файловых системах unix/linux больше связано с соглашениями и традициями, чем с абсолютной логикой.</p><p>в остальном я в основном согласен со всеми остальными. :-)</p><p>всегда есть какое-то исключение из правила. в конце дня вы решаете, что лучше для вашей установки (когда вы можете).</p>