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

21

Каковы "стандарты" - я должен поместить приложение (не просто бинарный, а весь дистрибутив) в / 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 и так далее. Скорее я спрашиваю о случае, когда вам нужно сохранить один основной каталог для всего приложения.

greenoldman
источник
6
Я думаю, что / opt является более привычным в этом контексте.
Фахим Митха
@ Фахим Митха, очень хорошая мысль. Благодаря вам я нашел такое объяснение "/ opt / 'provider' дерево каталогов, подобное тому, как Windows будет устанавливать новое программное обеспечение в свое собственное дерево каталогов C: \ Windows \ Progam Files \" Имя программы "с linuxtopia.org/ online_books / linux_beginner_books / ... Могли бы вы , пожалуйста ? разместим ваш комментарий как ответ, так что я бы пометить его как ответ Спасибо.
greenoldman
@greenoldman: также, пожалуйста, поймите, что хранение всех файлов в одном каталоге не является "стандартным" способом установки приложений в Unix. /optэто действительно правильный ответ, но он не «широко используется» традиционным программным обеспечением Unix / Linux. Есть веские причины разделять ваши файлы на несколько папок, а также отличаться /usrот них/usr/local
MestreLion
Например, хранение всех исполняемых файлов из всех приложений в одном /usr/bin(или /usr/local/bin) позволяет вашему $ PATH обращаться ко всему программному обеспечению без необходимости редактировать его для каждого программного обеспечения, чего нет в Windows
MestreLion

Ответы:

19

Я думаю, что / 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.

Фахим Митха
источник
5

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

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

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

symcbean
источник
Спасибо. Так что, если это аналогия с Windows, это должен быть / usr / local / SPECIAL_APP, а внутри должны быть его подкаталоги, верно?
Гринольдман
@ Greenoldman: Нет. Нет аналогия не подходит , так как для Windows и Linux используют различные модели: В окнах, вы обычно держите все файлы в одном директории, где в Linux вы обычно расколоть их на bin, share, libи т.д.
MestreLion
3

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

Тедди
источник
1
Из того, что я прочитал, / opt довольно распространен, только он не используется широко, но это не является сюрпризом, если вспомнить количество пакетов, доступных в репозиториях.
Гринольдман
0

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

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

Лишь для немногих пакетов я хотел бы добавить дополнительные пакеты /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и т.д.

Лаури Цили
источник
Давать советы, основанные на количестве пакетов, бесполезно; Как узнать, к какой группе принадлежит мой пакет?
Алоис Махдал
Кроме того, когда вы говорите «это рекомендуется», укажите источник справочной информации или четко заявите, что это ваша рекомендация (я полагаю, последняя ...?)
Алоис Махдал
И, между прочим, я не вижу, как в / opt будет меньше шансов запутать ваше приложение, чем при его распространении в / usr и т. Д. Мешать в других приложениях гораздо больше о правильном названии вещей и отсутствии ошибок в них. установить скрипты.
Алоис Махдал
Это определенно об именовании, которое запутывает вещи. Это то, что я испытал в прошлом, и поэтому мне нравится держать свои «лишние» пакеты отдельно от всего остального. Я все еще не хочу, чтобы все выглядело ужасно.
Лаури Цили
И да, вы правы насчет «рекомендуется», как вы можете видеть из моего ответа, который я использовал «я бы порекомендовал» повсюду. Теперь я исправил свое правописание и выяснил, почему я бы порекомендовал что-то. Опять же, это только моя точка зрения, а не окончательный ответ.
Лаури Цили