Установить программное обеспечение из пакетов или собрать его из исходного кода?

Вы должны использовать пакеты вашего дистрибутива, если у вас нет веских причин не делать этого. Использование пакетов дистрибутива дает вам важные преимущества:

• Это меньше работы, чтобы установить и удалить пакеты и поддерживать их в актуальном состоянии.
• Система упаковки автоматически установит зависимости программного обеспечения и обновит их.
• Обновления для системы безопасности автоматически предоставляются дистрибутивом, поэтому вам не нужно отслеживать их или беспокоиться о том, что вы их пропустили.
• Система упаковки настроит ваш любимый дистрибутив. Например, в системах, основанных на apt, Apache поставляется с символическими ссылками в /etc/apache2/*- с включенными инструментами (a2enconf, a2enmod, ...), чтобы использовать их для включения или отключения функций Apache. Хотя вначале вам может потребоваться больше усилий для изучения, в долгосрочной перспективе ваша жизнь станет проще, и ваша конфигурация будет лучше интегрирована, если вы будете использовать собственные инструменты и способы работы дистрибутива.

Если вам нужно использовать более новую версию программного обеспечения, чем предоставляет ваш дистрибутив, или включить функцию, которая должна быть скомпилирована, вы сможете найти более свежие или функциональные версии пакета из репозиториев сообщества. Репозитории Remi являются хорошо известным примером, предлагая среди прочего гораздо более современные версии PHP, чем те, которые поставляются с RHEL/CentOS. Использование репозитория сообщества дает вам много преимуществ репозиториев ОС, но есть риск, что автор выпускает вредоносное ПО, которое вы затем устанавливаете с полной привилегией в вашу систему. Вы должны будете самостоятельно оценить риск / вознаграждение в каждом конкретном случае.

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

• Работайте с системой управления пакетами вашего дистрибутива для распространения, установки, управления зависимостями, создания отчетов, обновлений, понижения и удаления.
• Ограничьте свои инструменты сборки и библиотеки разработки одним узлом сборки (а не устанавливайте их на всех тестовых и производственных серверах).
• Следуйте общему пути выпуска: сначала разверните свои пакеты в тестовой среде, а затем разверните этот же пакет в своей производственной среде.

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

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

Мне нравится ответ Эндрю.

Я хочу указать на конкретное замечание Эндрю о "лучшей интеграции". Если вы устанавливаете приложение из исходного кода (зависимость от будущего проекта), а затем пытаетесь установить пакет из двоичного файла (например, пакет deb или rpm), этот пакет может не распознать, что установлена ​​зависимость. Если бы вы установили начальное приложение зависимостей из пакета RPM или DEB, будущий пакет знал бы, что оно установлено. Использование одного и того же метода упаковки (например, yum, pip, rpm и т. Д.) Является наилучшей практикой. Установка из исходного кода - это еще один способ. Таким образом, легкость, о которой говорит Эндрю, является серьезным соображением.

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