Лучшая практика: где устанавливать пакеты Linux


0

Где лучший путь для установки всех файлов пакета при компиляции?

Например - я хочу установить ProFTPd, так что есть возможность

--prefix=/usr/local/proftpd

Это означает, что все файлы после компиляции (включая двоичные файлы и файлы конфигурации) будут храниться здесь. Как вы знаете, все пакеты, которые устанавливаются через систему пакетов (например, zypper в SuSE или apt в Ubuntu), обычно хранят свои файлы конфигурации в / etc / и двоичные файлы в / sbin /, а также хранят ссылку в моем $ PATH, поэтому я могу запустить, просто набрав proftpd (без / sbin).

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

Я думаю, что смогу создать какой-нибудь командный файл, который я смогу использовать так:

uninstall --package=proftpd

И мой скрипт найдет все файлы proftpd по обычным путям (/ etc, / sbin) и удалит их с помощью rm.

Есть ли рекомендации, где хранить все эти файлы, или есть какие-либо (не) преимущества моего первого примера (--prefix = / usr / local / proftpd)?

Я действительно не думаю, что хорошо иметь 2 пути с файлами конфигурации и двоичными файлами, но, возможно, я неправильно понимаю основные принципы Linux ... :-)

Ответы:


9

Стандарт иерархии файловой системы

Дистрибутив получает /usr, вы получаете /usr/local, ISV получают /opt.


1
Да, я понял вашу точку зрения, но есть ли (не) преимущества установки в / usr вместо / sbin? Как разрешения (безопасность) или ссылки?
Радек Симко

Если вы устанавливаете локальные пакеты на вашем компьютере в / usr / local, вы можете сделать резервную копию тех локальных пакетов, которые вы не можете сделать для / sbin. И да, вы не понимаете основных принципов файловых систем; например, почему бы вам не хранить каждый файл в одном каталоге?
MSS

2
Один недостаток при установке в / sbin -some дистрибутива linux предполагает наличие минимального запуска системы в / bin, / sbin и / lib, а затем всех остальных команд в / usr / bin, / usr / sbin и / usr / Lib. Некоторые дистрибутивы создают очень маленький раздел для хранения содержимого в /, а затем гораздо больший раздел для хранения содержимого в / usr. Поэтому проверьте, что пространство, доступное в / sbin -it, может быть ограничено.
Пэт Уоллес

4

Наилучшие места для установки пакетов на вашем компьютере - это /usr/localесли у вас есть права администратора и вы хотите, чтобы все использовали вашу программу, или $HOMEесли вы хотите просто сделать копию для себя.

Обычно вы устанавливаете префикс --prefix=/usr/localтак, чтобы файлы приложения сохранялись в /usr/local/binнастройках /usr/local/etcи т. Д.

Преимущество использования этих стандартных мест в том, что они стандартные. Люди знают, где искать файлы. Например, /usr/local/binон почти всегда у всех $PATH, так что вам не придется возиться с $PATHпеременной, чтобы заставить ее работать. Точно так же библиотеки обнаруживаются путем проверки, $LD_LIBRARY_PATHно /usr/local/libобычно проверяются по умолчанию, поэтому вам не нужно добавлять их вручную и так далее.

Относительно удаления: После того, как вы запустите, сконфигурируете и соберете программу, затем make installустановите ее для вас и make uninstallавтоматически удалите файлы.


1
Вы правы с make uninstall, но иногда это недоступно в пакете.
Радек Симко

Правда. Мне нравится идея checkinstall, упомянутая ниже. Я собираюсь попробовать это в следующий раз, когда я что-то установлю в Linux.
Пэт Уоллес

3

На самом деле, лучший подход, вероятно, заключается в создании пакета, который вы можете установить.

Многие приложения поставляются с необходимыми файлами для создания пакетов RPM или DEB. Если они этого не делают, есть инструменты для автоматического создания пакетов, например, checkinstall .

checkinstallбудет следить за операциями make installи перенаправлять установленные файлы, чтобы создать из них пакет DEB или RPM. Таким образом, вы получаете обычный пакет, который интегрируется с другими вашими пакетами.

Есть некоторые предостережения (вы не получите зависимости, а некоторые очень сложные сценарии установки могут потерпеть неудачу), но обычно это работает очень хорошо.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.