Как компилировать и устанавливать пакеты из исходников в Linux

Компиляция из исходников — полезный навык для разработчиков, системных администраторов и пользователей, которым нужна особая конфигурация ПО. В этом руководстве показан порядок действий на примере Git, а также даны рекомендации, подсказки и альтернативы.

Что вы получите из этой статьи

• Пошаговая инструкция по сборке и установке из исходников (пример: Git).
• Список необходимых инструментов и команд для популярных дистрибутивов.
• Чек-листы для ролей (разработчик, администратор, сборщик пакетов).
• Альтернативы, когда сборка не подходит, и практические советы по безопасности.

Основные термины в одну строку

• Исходники — исходный код программы, который можно перекомпилировать.
• Configure — сценарий, который проверяет зависимости и генерирует Makefile.
• Make — утилита для последовательной сборки проекта по инструкциям Makefile.

Шаг 1: Установка необходимых инструментов

Для сборки программ чаще всего требуются компилятор (GCC/Clang), инструменты разработки (make, cmake), а также dev-пакеты библиотек (включая -dev или -devel). Ниже — распространённые команды установки по дистрибутивам.

На дистрибутивах Debian/Ubuntu:

sudo apt update
sudo apt install build-essential cmake curl gettext libz-dev libssl-dev libcurl4-gnutls-dev libexpat1-dev

На Arch Linux и производных:

sudo pacman -Syu
sudo pacman -S base-devel cmake curl

На RPM-дистрибутивах (Fedora, RHEL, CentOS):

sudo dnf install @development-tools cmake curl dh-autoreconf curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel

Important: имена пакетов могут отличаться в вашем дистрибутиве. Если при запуске ./configure возникает ошибка о недостающем заголовочном файле, установите соответствующий -dev/-devel пакет.

Notes: Для параллельной сборки используйте make -j$(nproc) — это ускорит компиляцию, но повышает нагрузку CPU.

Шаг 2: Скачивание исходного кода

Мы возьмём Git как пример. Исходники обычно доступны на официальном сайте проекта или в репозитории (GitHub, GitLab, зеркала). Скачайте архив в папку Downloads и распакуйте.

cd ~/Downloads
curl --location --output git.tar.gz https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.26.2.tar.gz
# или
wget -O git.tar.gz https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.26.2.tar.gz

tar -zxf git.tar.gz
cd git-2.26.2

Совет: используйте –location для curl, чтобы следовать переадресациям.

Шаг 3: Подготовка и проверка зависимостей

Прежде чем компилировать, посмотрите README, INSTALL или другие файлы с инструкциями. Запустите configure, если он присутствует — скрипт проверит окружение.

./configure

Если configure отсутствует, проект может использовать CMake или другую систему сборки:

# для CMake-проекта
cmake .
# или
mkdir build && cd build
cmake ..

Ошибки на этом шаге обычно связаны с отсутствием dev-библиотек, pkg-config или корректных переменных среды (PATH, PKG_CONFIG_PATH). Устраняйте зависимости по сообщениям конфигуратора.

Шаг 4: Сборка (make)

Запустите make. Для ускорения используйте опцию -j с числом потоков, равным ядрам процессора.

make
# или параллельно
make -j$(nproc)

Make использует Makefile, сгенерированный configure или поставляемый вместе с исходниками. Периодически полезно смотреть вывод сборки на предмет предупреждений и ошибок — они подскажут, что нужно исправить.

Шаг 5: Установка собранного пакета

После успешной сборки установите пакет в систему:

sudo make install

Или установите в локальный префикс (например, /usr/local) без затрагивания системных файлов:

./configure --prefix=/usr/local
make -j$(nproc)
sudo make install

Проверим версию Git, чтобы убедиться в правильной установке:

git --version

Обычно новая версия будет в /usr/local/bin, а системный менеджер пакетов может продолжать считать установленную версию из репозиториев старой. Чтобы избежать конфликтов, либо удалите дистрибутивную версию, либо ставьте в префикс, который стоит раньше в PATH.

Рекомендации и лучшие практики

• Сборка в чистой среде: используйте chroot, systemd-nspawn, Docker или LXC для изоляции.
• Создавайте пакет вместо прямого make install: checkinstall или инструменты сборки дистрибутива (debbuild, rpm, pbuilder, mock).
• Храните патчи отдельно: если вы вносите изменения в код, сохраняйте патчи через git или quilt.
• Логи: сохраняйте лог сборки (make 2>&1 | tee build.log) для отладки.

Команды-чит: быстрый набор

# распаковка
tar -xzf package.tar.gz
# рекурсивная сборка
./configure --prefix=/usr/local
make -j$(nproc)
# вместо sudo make install — создать пакет (простая опция)
sudo apt install checkinstall  # на Debian/Ubuntu
sudo checkinstall
# удалить ранее установленную версию (пример для apt)
sudo apt remove git

Когда сборка из исходников не подходит (контрпримеры)

• Нужно быстро установить ПО на множество машин — лучше использовать пакеты репозитория, Ansible, контейнеры или образ.
• В средах с жёсткой политикой контроля версий и пакетов (корпоративные репозитории): сборка вручную может нарушить соответствие.
• Отсутствие исходников/закрытый код — сборка невозможна.

Альтернативные подходы

• Установка через менеджеры пакетов: apt, dnf, pacman.
• Универсальные контейнерные форматы: Snap, Flatpak, AppImage.
• Сборка пакетов для дистрибутива: создание .deb или .rpm и последующее распространение.
• Использование предсобранных бинарных релизов проекта.

Ментальные модели / эвристики

• «Сначала проверяй зависимости»: если configure падает — сначала установи dev-пакеты, затем повтори.
• «Сначала в изолированной среде»: тестируй сборку в контейнере, чтобы не повредить хост.
• «Не доверяй sudo make install»: лучше собрать пакет, чтобы иметь возможность удалить или обновить программу демократично.

Чек-листы по ролям

Разработчик:

• Проверить README/INSTALL.
• Запустить автотесты: make test или make check.
• Собрать локально, запустить базовую функциональность.

Системный администратор:

• Сравнить с дистрибутивной версией.
• Собрать пакет (.deb/.rpm) и развернуть на тестовом узле.
• Автоматизировать развертывание (Ansible, Salt, Puppet).

Сборщик пакетов:

• Настроить chroot/pbuilder/mock.
• Создать чистую сборочную среду.
• Подготовить метаданные пакета и скрипты установки.

Тестировщик:

• Составить набор smoke-тестов.
• Проверить совместимость с критичными библиотеками и версионированием.

Критерии приёмки

• Программа успешно запускается и проходит базовый сценарий использования.
• Версия соответствует ожидаемой (git –version).
• Файлы установлены в ожидаемые директории и не конфликтуют с дистрибутивными пакетами.
• Полный лог сборки доступен и не содержит критических ошибок.

Риск-матрица и смягчение рисков

• Конфликт версий (системный git vs локальный): смягчение — использовать префикс /usr/local или удалить дистрибутивный пакет.
• Повреждение системы при sudo make install: смягчение — тестировать в контейнере и собирать пакет.
• Уязвимости в исходном коде: смягчение — проверять сигнатуру релиза и исходников.

Безопасность и проверка целостности

• Проверяйте PGP/GPG-подписи релизов (если доступны).
• Сравнивайте checksum (sha256/sha512) архива.
• Собирайте в изолированной среде, чтобы минимизировать влияние на систему.

Советы по отладке типичных проблем

• “Header not found”: установите соответствующий -dev/-devel пакет.
• “Undefined reference”: проверьте порядок линковки и наличие -lпакет.
• “Permission denied” при make install: используйте sudo или смените префикс на домашний каталог для тестирования.

Пример: создание простого .deb через dpkg-deb (микроподход)

1. Соберите проект в отдельную директорию, например build.
2. Создайте структуру DEBIAN и нужные папки bin/lib и поместите туда бинарные файлы.
3. Заполните файл DEBIAN/control (имя пакета, версия, зависимости).
4. Соберите пакет:

cd package_root
dpkg-deb --build . ../my-package.deb

Этот подход полезен для быстрого разворачивания на нескольких серверах без администрирования исходных make install.

Решение: какой способ выбрать? (диаграмма)

flowchart TD
  A[Нужно установить ПО?] --> B{Требуется модификация кода?}
  B -- Да --> C[Собрать из исходников]
  B -- Нет --> D{Требуется быстро и на многих машинах?}
  D -- Да --> E[Установить из репозитория или собрать пакет .deb/.rpm]
  D -- Нет --> F{Хотите изоляцию/простоту обновления?}
  F -- Да --> G[Использовать контейнер/Flatpak/Snap]
  F -- Нет --> H[Скачать предсобранный бинарник или собрать локально]

Совместимость и заметки по миграции

• При переходе между дистрибутивами следите за именами dev-пакетов и версиями библиотек.
• Используйте pkg-config для обнаружения библиотек во время конфигурации.
• Для многоцелевых сборок рассмотрите использование CMake с опцией -DCMAKE_INSTALL_PREFIX.

Краткая сводка (Summary)

• Сборка из исходников даёт гибкость, но требует контроля зависимостей и внимания к совместимости.
• Всегда тестируйте в изолированной среде и по возможности создавайте пакет, а не выполняйте прямую установку.
• Используйте инструменты для проверки подписи и контроль версий, чтобы снизить риски.

Если нужно, могу подготовить: шаблон скрипта для сборки .deb, пример Dockerfile для изолированной сборки или готовый playbook Ansible для разворачивания скомпилированного пакета на нескольких серверах.