Вы правы, считая, что это не лучший маршрут. Этот маршрут требует много ручных шагов, он очень подвержен ошибкам и плохо масштабируется.
При работе с дистрибутивами Linux вам следует как можно больше придерживаться управления пакетами.
Преимущества использования управления пакетами:
- Поддержка зависимостей
- Простота установки / удаления
- Инвентаризация программного обеспечения
- Поддержка Upgrade / Downgrade, включая обработку файлов конфигурации
- Исходный пакет в основном документирует ваш процесс сборки и автоматизирует его после того, как он будет написан.
- Подписание пакета
- и больше.
Когда вы начинаете работать только из исходного кода, вы теряете все эти замечательные функции, и все становится довольно быстро.
Чтобы решить вашу особую проблему, вы должны проверить репозиторий бэкпортов Ubuntu , возможно, у них есть обновленная версия для NGinx, которую вы можете использовать.
Если у них нет подходящей версии, то лучшим решением было бы создать бэкпортированный пакет ubuntu самостоятельно. Это на самом деле не так сложно, и это менее трудоемко, чем каждый раз компилировать его из исходного кода вручную. Backporting требует, в основном, взять исходный пакет из Ubuntu, заменить старый файл tar.gz upsteam на последний, который вы хотите, и пересобрать пакет.
Вы можете использовать это руководство, чтобы помочь вам сделать бэкпорт пакета.
В следующий раз ... как насчет компиляции в * .rpm или * .deb?
источник
Если вы собираетесь установить это на одной машине, то делать это каждый раз из исходного кода - проблема наилучшего способа. Если вы собираетесь установить его на нескольких компьютерах и хотите убедиться, что он совместим, вероятно, стоит научиться создавать пакеты Debian. Возможно, вы могли бы использовать упаковку в Ubuntu в качестве основы.
источник
Там не отличный способ. Причина, по которой было создано эффективное управление пакетами, заключалась в том, чтобы решить эту проблему. Обновление и удаление скомпилированных исходных кодов проблематично.
Я согласен с Томом и Дэвидом.
Если это одноразовый случай, то, вероятно, лучшим вариантом будет повторная компиляция из исходного кода. Если он находится на множестве машин, самое время перейти к управлению поддерживаемыми пакетами.
источник
Боюсь, это единственный способ. если у вас есть больше серверов для обслуживания - рассмотрите возможность создания отдельной тестовой среды, в которой вы компилируете, и, возможно, упаковываете результаты своей компиляции.
это немного стандартизирует ваши настройки и упростит развертывание на многих серверах. Кроме того, вам не понадобится gcc на производственных машинах [что многие считают преимуществом безопасности].
источник