Должен ли я поместить приложение в / usr / local или / usr / local / share?

Каковы "стандарты" - я должен поместить приложение (не просто бинарный, а весь дистрибутив) в / usr / local или / usr / local / share.

Например, scala или weka - он содержит примеры, двоичные файлы, библиотеки и так далее. Так было бы

/usr/local/scala-2.9.1 

или

/usr/local/share/scala-2.9.1

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

Важно: я не спрашиваю о случаях, когда вы должны разделить приложение на / usr / local / bin, / usr / local / lib и так далее. Скорее я спрашиваю о случае, когда вам нужно сохранить один основной каталог для всего приложения.

Я думаю, что / opt является более стандартным в этом контексте. Соответствующий раздел в Стандарте иерархии файловой системы приведен ниже.

Дистрибутивы могут устанавливать программное обеспечение в / opt, но не должны изменять или удалять программное обеспечение, установленное локальным системным администратором без согласия локального системного администратора.

 Обоснование Использование / opt для дополнительного программного обеспечения является общепринятой практикой в ​​сообществе UNIX. Двоичный интерфейс приложения System V [AT & T 1990], основанный на определении интерфейса System V (третье издание), обеспечивает структуру / opt, очень похожую на определенную здесь.

Стандарт двоичной совместимости Intel v. 2 (iBCS2) также предоставляет аналогичную структуру для / opt.

Как правило, все данные, необходимые для поддержки пакета в системе, должны присутствовать в / opt /, включая файлы, предназначенные для копирования в / etc / opt / и / var / opt /, а также зарезервированные каталоги в / opt.

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

Структура каталогов ниже / opt / оставлена ​​на усмотрение упаковщика программного обеспечения, хотя рекомендуется, чтобы пакеты устанавливались в / opt // и следовали структуре, аналогичной рекомендациям для / opt / package. Действительная причина отклонения от этой структуры - для пакетов поддержки, в которых могут быть файлы, установленные в / opt // lib или / opt // bin.

Вы должны использовать только /usr/local/shareдля файлов, которые не являются специфическими для конкретной версии архитектуры / ОС.

После этого он до вас распространять ли файлы между существующими подкаталогами из /usr/localили если вы создаете новый специализированный каталог в /usr/local(но последняя воля не существует на исполняемом файле PATH, то LD_LIBRARY_PATH, ни MANPATH).

Посмотрите на FHS

Пока не /optстало обычным, обычное место было /usr/local/lib/<package>.

При установке локальных приложений, есть несколько вариантов, в зависимости от того, как вы хотите получить доступ и обновить. Также следует отметить, что некоторые методы больше похожи на систему, которая у вас уже есть, а некоторые более специализированы. Я бы предположил, что «лучшие» решения - это те, которые облегчают управление.

Я разделил этот ответ в зависимости от количества пакетов, для которых нужно выполнить пользовательские установки. Расщепление основано на моем собственном опыте. Эти события взвешивают время, необходимое для управления пакетами, и риски что-то испортить. Я не имею в виду, что у меня есть знания общих стандартов, но имею в виду это как ориентир, который нужно учитывать при принятии решения.

Лишь для немногих пакетов я хотел бы добавить дополнительные пакеты /opt, где они находятся вне пути всего остального, поэтому ничто не может испортить их, и они могут испортить что-то еще. Это метод, который я использую на моем NAS. Этот метод, однако, сохраняет двоичные файлы вне вашей переменной PATH, поэтому вам нужно будет добавить их вручную. Это хорошо работает, если нужно установить только несколько пакетов, но становится беспорядочным, если их много.

Обновление здесь довольно просто, поскольку вы просто перезаписываете каталог.

Плюсы:

• просто
• быстро настроить
• нет шансов повлиять на другие части системы
• удалить так же просто, как установить

Минусы:

• Становится довольно утомительным, если количество пакетов для установки велико
• Выглядит PATHгрязно

Для более чем нескольких пакетов я бы порекомендовал использовать /usr/local/<your package>исполняемый файл и sym-linking из /usr/local/binили в /usr/local/sbinзависимости от того, нужны ли вам права root. Это избавляет вас от изменения вашей PATH каждый раз, когда добавляется что-то новое, поэтому PATH остается чистым. Этот метод я использую на своем ноутбуке Arch для всех пакетов не pacman и AUR.

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

Pros

• Не делает PATHгрязный
• Не влияет на базовую систему
• По-прежнему очень просто удалить все надстройки и вернуться к чистой базовой системе

Минусы:

• Больше работы по настройке
• Удаление только одного пакета требует некоторого поиска

Для многих пакетов . Поскольку это не тот случай, который вы хотите, я буду кратким. Я бы рекомендовал Нарезка пакет в bin, lib, shareи т.д. , и установка их /usr/local. Это должно держать структуру в чистоте. Вы также можете указать, кто может написать, где и больше. Например, вы не хотите, чтобы другие пользователи, кроме root, модифицировали исполняемый файл.

Здесь обновление становится немного сложнее, так как вам нужно писать в более чем один каталог. Я бы порекомендовал упаковать все это и позволить менеджеру пакетов обработать все остальное.

Доля

shareСам каталог для архитектуры независимых файлов , как указано в Фахим по ссылке и зависимые файлы архитектуры должны идти lib, lib32, lib64и т.д.