Яка різниця між / 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і все його дочірні каталоги знаходяться у відповідному окр вари , такі як 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,...}тощо.