Как собрать пакет из исходников ubuntu

Обновлено: 04.07.2024

Бывают ситуации, когда вам нужна самая свежая версия программы, но её нет в репозитории вашего дистрибутива. Или эту программу вообще туда не добавляют по каким-то причинам. Вариантов получить эту программу тут несколько, один из них - собрать программу из исходного кода, непосредственно под ваш дистрибутив. Разумеется речь идёт о программах с открытым исходным кодом :)

Сборка (компиляция) программы - это превращение её исходного кода, написанного на каком-нибудь компилируемом языке программирования (например C++), который понятен программисту, в бинарный код (последовательность нулей и единиц), который понятен центральному процессору компьютера. Не все языки программирования являются компилируемыми. Например код на языке Python, можно запускать сразу, без перевода его в бинарный код (хотя и это возможно). Для сборки программы, желательно иметь достаточно мощный, и желательно многоядерный процессор. Ни в коем случае не компилируйте программы на ноутбуках! Это крайне негативно скажется на продолжительности их жизни (они не рассчитаны на такие нагрузки, если конечно у вас не игровой ноутбук).

В сборке программы из исходного кода нет ничего сложного. Главное помнить одно правило: в пакетном дистрибутиве ни в коем случае нельзя использовать метод make install. Иначе в будущем получите большую такую кучу проблем. Когда поймёте, что хотели удалить программу (поставленную таким образом), а пакетный менеджер о ней не знает. А сама программа состоит из нескольких сотен файлов, разбросанных по разным каталогам. Страшно? Поэтому в пакетных дистрибутивах, программу нужно собирать в, собственно, пакет. Тогда её можно будет без проблем удалить, в случае чего. Я написал это потому что многие руководства по компиляции программ в Linux, которые мне попадались, описывают именно make install. Удалить программу, установленную таким образом можно только в двух случаях:

если у вас остался архив с её кодом (тогда можно выполнить make uninstall);
если исходный код программы поддерживает это.

Отмечу, что не каждую программу можно собрать одним и тем же способом. Поэтому всегда нужно читать инструкцию по сборке, которая есть в архиве с исходным кодом. Бывает что разработчик положил туда скрипт, который при запуске делает всё сам (собирает и устанавливает, но мы помним про make install), или для сборки может не подойти make, а нужна другая система сборки. Также для сборки программы, необходимо будет установить нужные для неё сборочные зависимости (это пакеты с префиксом -dev). Для того чтобы быстро собрать программу в пакет, дабы иметь возможность без проблем её установить или удалить, существует утилита, под названием checkinstall. Она позволит создать родной для системы пакет (deb или rpm), что позволит использовать штатный пакетный менеджер для её установки/удаления

Сперва нужно подготовить систему. Для этого установим необходимый набор инструментов:

sudo apt install build-essential gcc devscripts git fakeroot automake autoconf

так и скопировать весь репозиторий себе (как это делают разработчики). Для примера возьмём программу mgba. Это эмулятор игровой консоли Nintendo GameBoy. Адрес репозитория здесь. Копируем его себе:

В домашнем каталоге у вас появится директория с его исходным кодом. На той же странице программы, есть инструкция по сборке.

Внимательно читаем. Открываем терминал и переходим в каталог с исходным кодом:

И собираем программу:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..
make
sudo checkinstall -D

Возьмём немного другой пример, в котором используется конфигуратор. В таком случае, в директории с исходным кодом, располагаются скрипты: autogen.sh, configure и подобные. Autogen.sh генерирует скрипт configure, с помощью которого уже можно сконфигурировать программу перед сборкой (да да, конфигуратор конфигуратора). Как всегда не забываем читать инструкцию по сборке той или иной программы. Предположим, что в архиве есть скрипт autogen.sh . Выполним его:

После выполнения, должен появиться файл configure. Чтобы посмотреть с какими параметрами можно собрать программу, введите:

Просмотрите все доступные параметры. Обычно, это могут быть поддержки различных плагинов, сборка с альтернативным интерфейсом, даже сборка под другую процессорную архитектуру. Допустим программа использует интерфейс, написанный на GTK+ 2, но имеет альтернативный на GTK+ 3. Тогда конфигурация программы будет выглядеть так:

Всё подробно будет описано в инструкции. Есть некоторый набор стандартный опций (после ввода ./configure --help, они пишутся вначале), таких как указание пути для установки:

После запуска configure и успешного конфигурирования кода, можно запустить сборку:

Вот и всё. Как видите, здесь нет ничего сложного. Хотя, не стану скрывать, бывает так, что разработчик не озаботился качественной инструкцией по сборке. Но такое бывает редко. Хочу также обратить ваше внимание на следующее: прибегайте к сборке программы из исходников только в крайнем случае. Если вы используете Ubuntu LTS, то посмотрите (при помощи гугла), нет ли необходимой вам программы (или свежей версии) в более свежем выпуске Ubuntu. Или возможно есть PPA-репозиторий, где всегда есть свежие версии этой программы. В Debian с этим сложнее, но зачастую можно взять более свежую версию программы из ветки testing или даже unstable, и она нормально установится и будет работать. И только убедившись, что больше вариантов нет - прибегайте к компиляции. В следующий раз я напишу о профессиональном способе сборки deb-пакетов, каким пользуюсь я (и другие разработчики, собирающие пакеты для Debian-based систем). Если что-то упустил - пишите в комментариях.

Дистрибутивы, основанные на Debian – это не только отличная система управления пакетами APT, которая сама разрешает зависимости, но и удобные инструменты для создания пакетов и своих репозиториев. Если уж вы решились собрать программу из исходников, то советую ещё изучить, как дебианизировать исходники. Это отнимет чуть больше времени, чем стандартное

но зато позволит сохранить систему в чистоте. Удалить программы, установленные командой make install, можно только командой

но не все исходники это поддерживают, а что ещё чаще - исходники удаляют после установки, тогда удалить программу можно только вручную. Но чтобы это сделать, нужно точно знать что и куда установилось. А это уж точно никто не знает, кроме самих разработчиков программы (ну или тех, кто более-менее разбирался в исходниках программы).

APT не знает ничего о программах, установленных вручную. Соответственно, могут быть конфликты, или просто непонятные ошибки. Очень часто исходники по умолчанию «рассчитаны» на определённый дистрибутив, или, наоборот, рассчитаны только на установку из исходников, при этом выполняются разного рода «удобные» настройки в конфигурационных файлах. Так, например, очень любят прописывать mime-типы. Но проблема в том, что переводы разные бывают и в Nautilus может выскочить ошибка

и документ не будет открываться. Таких «недочётов» может быть очень много. А теперь, если представить что это удалить нельзя, поскольку пользователь не запоминал что и куда поставилось, наступает паника и как результат - переустановка.

Но как быть, если программу хочется поставить, а версия в deb-пакете устарела, или такой вообще нет? Использовать программу checkinstall . Она собирает всё в один пакет. К сожалению, она позволяет решить только вопрос с удалением программы. И даже если APT будет знать, что программа установлена, он в лучшем случае сообщит, что есть конфликт файлов,

Чаще всего такие случаи очень корректно разрешаются путём удаления конфликтного пакета. Но на разбор ситуации уйдёт некоторое время.

Cобрать нормальный пакет, как это делают мантейнеры. В котором будет корректная версия, зависимости и расположение файлов будет соответствовать политике дистрибутива. Вижу вам всё ещё интересно . Это радует.

Возможны следующие случаи сборки пакетов:

исходники или бинарные файлы берутся:

из репозитория другого выпуска Ubuntu, из PPA или из Debian; берётся из репозитория Ubuntu, из PPA или из Debian: ни в репозитории Ubuntu текущего выпуска, ни в PPA нет нужной версии программы; доступная версия программы по каким-либо причинам не устраивает (не устраивает код или данные программы, параметры конфигурации или управляющая информация пакета); Дано: некий исходник gcoolprog-0.5.3.tar.bz2. Нужно из него собрать пакет. Решение: ниже идёт вариант, как я обычно поступаю в таком случае. Первым делом смотрю, нет ли deb-пакета той же версии, но допустим под Debian. Если есть делаю так: есть нужная версия пакета в репозитории debian или в будущем релизе Ununtu Если нет той же версии, но есть предыдущей. Тут можно сказать как повезёт, если изменения в исходниках не коснулись положения файлов, то скорее всего дебианизация от старого пакета подойдёт, нужно лишь сменить версию. Теперь вариант в репозитории есть пакет предыдущей версии. Ну и самый страшный случай - нигде никаких deb-пакетов нет, только tar.gz и rpm. Ни в коем случае не использовать rpm! Делаем по первому варианту.

Что необходимо

Полное Руководство начинающего разработчика Debian доступно тут.

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

Нам понадобятся как минимум программы, устанавливаемые командой

Можно так же autobook - это документация по утилитам GNU Autoconf , Automake , и Libtool . Ну и конечно то, что требуют сами исходные коды для корректной сборки.

Создание ключа шифрования

Этот шаг не обязателен, его можно пропустить.

Чтобы создать ключ, зайдите в Приложения → Стандартные → Пароли и ключи шифрования. В открывшемся окне, в меню Ключ → Новый ключ, выбираем ключ pgp. Заполняем поля Полное имя и Электронный адрес.

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

Хотя последняя версия программы seahorse имеет демон, который автоматически запускается в сеансе GNOME, и умеет «запоминать пароль» на время сеанса, но пока не все программы умеют с ней работать.

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

/.bashrc, или в другой стартовый скрипт, вашего любимого шелла (для zsh

/.zshrc), нужно вписать переменные

На основании e-mail будет искаться ключ в pgp, при подписи пакета.
Нужно завершить сеанс и зайти заново, чтобы изменения вступили в силу.
Помните, что если вы бэкпортируете пакет, дебианизированный не вами, обязательно нужно изменить версию командой

для того, чтобы в изменения вписался ваш e-mail. А для того, чтобы ваш открытый ключ попал на сервер, необходимо в настройках «seahorse → Пароли и ключи шифрования», настроить соединение с сервером публичных ключей.
Для этого, в меню Правка→Параметры на закладке Публикация ключей необходимо поставить галку Публиковать ключи….
Теперь можно выбрать ключ и в меню по правой кнопке выбрать Синхронизировать и опубликовать ключи.

Дебианизация недоступна

Итак, у нас есть только gcoolprog-0.5.3.tar.gz.

Обычно я выполняю следующие действия:

Предварительно подготавливаю рабочую директорию

Получаем файл gcoolprog-0.5.3.tar.gz. Распакуем его перейдем в полученный каталог:

Для корректной сборки нужно, чтобы корневая директория содержала не только название, но и версию!

Ниже будем считать директорию

/src/gcoolprog/0.5.3/gcoolprog-0.5.3 корневой директорией исходников.
Далее выполняем «черновую» сборку. Т.е. сконфигурируем и соберем приложение, без его установки:

Если команда выполнилась успешно, то осталось только дебианизировать.

Дебианизация

Ничего страшного в этом нет, как я уже говорил есть скрипты, которые сильно упрощают этот процесс.
Вообще смысл всей этой процедуры - создать директорию debian в корне исходников, с нужными файлами конфигурации и скриптом(ами).
Для этого, в корне исходных текстов, выполним

На что мы должны получить следующий диалог

Тут мы указываем сформировать пакет, для одиночного бинарного файла.

Но мы с вами молодцы и всё у нас прошло без ошибок - появился каталог debian в корне исходников, посмотрев его содержимое, Вы увидите кучу файлов (расширение .ex) с примерами на все случаи жизни.

Будем считать, что программа у нас простая – обычно ни один из этих файлов не нужен.
Первым делом, нужно добавить описание программы в файле debian/control

без этого мы получим пустой пакет.
Иногда debian/rules содержит лишь:

Что приемлемо с использованием debhelper.
Этих настроек будет достаточно для сборки пакета с одной программой, которая не содержит разделяемых библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share.

Сборка пакета

Теперь, соберём пакет:

В директории выше, т.е. в

/src/gcoolprog/0.5.3, мы получим файлы

Вот теперь мы можем установить пакет

Дебианизация берётся из репозитория Ubuntu, из PPA или из Debian

Дебианизация берётся из другой версии программы

Как я уже сказал, возможно нам повезёт и достаточно будет только сменить версию. Но не будем гадать.

Ниже я не буду комментировать то, что описано в предыдущем решении.

Предварительно подготовим рабочую директорию

получаем файл gcoolprog-0.5.3.tar.bz2

теперь распаковываем его

копируем каталог gcoolprog-0.5.1/debian в директорию

дальше нам нужно изменить версию командой

этой командой изменяется файл debian/changelog например увидим

но поскольку у нас версия 0.5.3, то нужно изменить значения на

сохраните изменения. Теперь можно выполнить команду сборки в пакет.

Дебианизация берётся из текущей версии программы

Дебианизация берётся не из репозитория текущего выпуска Ubuntu

Предварительно подготовим рабочую директорию

теперь скачиваем три файла

или тоже самое, но одной командой

из пакета devscripts
затем распакуем командой

получим каталог gcoolprog-0.5.3.Перейдём в него и сменим версию:

теперь можно собирать пакет

Дебианизация берётся из репозитория текущего выпуска Ubuntu

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

Для сборки понадобятся следующие пакеты: build-essential devscripts fakeroot. Потребуются также пакеты для разработки, мы их установим в дальнейшем.

apt-get source скачивает исходники из репозитория Ubuntu в текущую директорию. Многие пакеты в репозитории имеют общие друг с другом исходники, поэтому кроме исходников выбранного пакета могут скачаться и исходники других пакетов (общие для нескольких пакетов исходники).

Далее вносим изменения в исходники и собираем из них обратно пакеты.

Устанавливаем необходимые для сборки пакеты для разработки:

Ниже идёт пример как можно поступить в случае, если доступен только deb-пакет и нет его дебианизированных исходников.

Для начала советую прочитать это. И это. Тут полная документация на русском.

Предположим, что работаем в каталоге

/tmp. Создадим подкаталог

/tmp/someprog, чтобы распаковать файлы какого-нибудь пакета, нужно выполнить

Для того, чтобы извлечь контрольную информацию, выполним

ну а теперь, чтобы всё это собрать обратно в пакет, нужно выполнить

/tmp/someprog/DEBIAN содержатся файлы, описывающие, что это за пакет, от чего он зависит, и контрольные суммы файлов, находящихся в нём. Для того, чтобы собрать свой пакет, нужно поместить файлы в каталоге

/tmp/someprog так, как будто это корневой каталог.То есть, если нужно, чтобы файл установился в /usr/bin,нужно его поместить в каталог

/tmp/someprog/usr/bin, ну и, соответственно, если что-то должно лежать в /etc, то в

/tmp/someprog/etc и т.д.

/tmp/someprog создать каталог DEBIAN, обязательно большими буквами, и в нём файл

/tmp/someprog/DEBIAN/control, в этом файле описывается название пакета, его зависимости и описание, формат очень простой. Например:

Ну а теперь собрать:

Данная инструкция является шпаргалкой по сборке пакетов для deb-систем (Debian, Ubuntu, Mint и так далее). Мы рассмотрим пример работы с исходниками nginx, а также разберем подробнее опции, которые можно задействовать при сборке. На практике, данное действие не имеет смысла, так как уже собранный nginx можно получить на сайте разработчика или в репозитории системы, но для нас важно понять процесс сборки, после чего можно будет применить данные знания для своих проектов.

Подготовка системы

Процесс сборки требует установки дополнительных компонентов, что приводит к скоплению мусора из ненужных пакетов. Рекомендуется делать сборку на отдельном компьютере или в контейнере Docker. Подробнее об установке последнего в инструкции Установка Docker на Linux.

Независимо от среды, в которой мы будем собирать пакеты, необходимо выполнить предварительные настройки.

1. Установка пакетов:

apt-get install dpkg-dev devscripts wget

2. Создание пользователя.

Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним. Однако, если мы работаем в специальной виртуальной среде или контейнере Docker, нам это не страшно. Тогда данный пункт можно пропустить и работать из-под root.

useradd builder -m

* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.

Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:

3. Создадим каталог, в котором будет происходит сборка:

mkdir -p debbuild

Перейдем в debbuild:

Мы готовы к сборке.

Сборка из исходников

В нашем примере мы возьмем исходники для сборки nginx (для выполнения configure, make, make install . ) и соберем из них свой пакет для установки NGINX. Процесс будет разбит на несколько этапов:

Предварительная настройка.
Создание файлов с инструкциями для сборки пакета.
Выполнение сборки и проверки.

Рассмотрим каждый из этапов подробнее.

Подготовка

Создадим каталог с названием собираемого приложения (с учетом версии):

mkdir -p nginx-1.20.1/debian

* в нем обязательно каталог debian.

Перейдем в созданный каталог:

Теперь создадим несколько важных файлов.

Создание файлов сборки (основные)

Для выполнения сборки нужно создать, минимум, 4 файла.

1. Control-файл.

Это основной файл с описанием процесса сборки. Вводим:

Пример для нашего случая:

* значения для опции Build-Depends задаются экспериментально — лучше всего попробовать сначала собрать требуемый пакет вручную, чтобы понять, какие потребуется доустановить пакеты. Рекомендуется это делать на чистой системе, чтобы не получить искаженный результат (на используемой системе уже могут быть пакеты, которых не будет на другом компьютере, где будет происходить сборка).
* более подробное описание файла control представлено ниже.

2. Файл changelog.

В данном файле описывается история изменений пакета. Также сборщик берет из этого файла номер версии и релиза.

Создаем файл командой:

* в файле указано, что первые изменения внес Dmitriy Mosk 03 августа. Для начала сборки этого будет достаточно. Описание ниже.

3. Файл rules.

Описываем правила компиляции пакета во время его сборки. Создаем файл:

* важно обратить внимание на факт, что содержимое файла может сильно отличаться в зависимости от того, что мы собираем и какой версии собираемое программное обеспечение. В данном примере мы создали файл для независимой работы — сборщик сам скачает исходник и распакует его в рабочий каталог (в данном примере, nginx). Также мне пришлось переопределить этап dh_usrlocal, так как на нем возникала ошибка, связанная с невозможностью удалить каталог командой rmdir.
* в нашей системе должен быть установлен wget, как и все остальные утилиты, которыми мы захотим воспользоваться.
* более подробное описание файла rules ниже.

4. Файл compat.

Указываем на уровень совместимости с debhelper (вспомогательный инструмент для сборки пакетов). Создаем файл:

* на момент обновления инструкции рекомендовано использовать версию не ниже 9. Сама по себе сборка без данного файла (или при указании версии ниже 9) запустится, но быстро остановится с ошибкой dh_auto_clean: Compatibility levels before 9 are deprecated (level X in use), где Х — текущий уровень совместимости.

Дополнительные файлы сборки

Данные файлы не являются обязательными. Они могут увеличить возможности собираемого пакета, а также нужны для нашего удобства.

1. Файл postinst.

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

* в данном примере мы просто создадим учетную запись dmosk. Опция set -e говорит о том, что при возникновении ошибки, необходимо сразу прервать работу скрипта.

Может быть использован более сложный сценарий с обработкой аргументов, например:

case "$1" in
configure)
systemctl is-enabled --quiet nginx && systemctl disable nginx
;;

upgrade)
systemctl is-active --quiet nginx
;;

* таким образом, при установке приложения посредством, например, команды apt-get upgrade, после инсталляции будет выполнена только команда sytemctls is-active --quiet nginx.

2. Файл postrm.

Это скрипт, который выполнится после удаления пакета:

rm -rf /var/log/app
rm -rf /opt/app/test

* в данном примере мы предположили, что после удаления нужно удалить 2 каталога /var/log/app и /opt/app/test.

3. Файл preinst.

Скрипт выполнения перед установкой пакета.

4. Файл prerm.

Скрипт выполнения перед удалением пакета.

Сборка пакета

У нас созданы все необходимые файлы, выполнены предварительные действия, и мы готовы к сборке.

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

* команда является частью пакета devscripts, который мы установили в начале инструкции. Она читает опцию Build-Depends файла control и устанавливает необходимые пакеты.

Выполним сборку командой:

debuild -us -uc -b

Если мы все сделали правильно, в конце мы увидим что-то на подобие:

W: nginx: missing-depends-line
E: nginx: no-copyright-file
E: nginx: description-starts-with-package-name
E: nginx: dir-in-usr-local usr/local/nginx/
E: nginx: dir-in-usr-local usr/local/nginx/conf/
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi.conf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi.conf
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi.conf.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi.conf.default
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/koi-utf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/koi-utf
E: nginx: file-in-usr-local usr/local/nginx/conf/koi-win
W: nginx: file-in-unusual-dir usr/local/nginx/conf/koi-win
E: nginx: file-in-usr-local usr/local/nginx/conf/mime.types
W: nginx: file-in-unusual-dir usr/local/nginx/conf/mime.types
E: nginx: file-in-usr-local usr/local/nginx/conf/mime.types.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/mime.types.default
E: nginx: file-in-usr-local usr/local/nginx/conf/nginx.conf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/nginx.conf
E: nginx: file-in-usr-local usr/local/nginx/conf/nginx.conf.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/nginx.conf.default
E: nginx: file-in-usr-local usr/local/nginx/conf/scgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/scgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/scgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/scgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/uwsgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/uwsgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/uwsgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/uwsgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/win-utf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/win-utf
E: nginx: dir-in-usr-local usr/local/nginx/html/
E: nginx: file-in-usr-local usr/local/nginx/html/50x.html
W: nginx: file-in-unusual-dir usr/local/nginx/html/50x.html
E: nginx: file-in-usr-local usr/local/nginx/html/index.html
W: nginx: file-in-unusual-dir usr/local/nginx/html/index.html
E: nginx: dir-in-usr-local usr/local/nginx/logs/
E: nginx: dir-in-usr-local usr/local/nginx/sbin/
E: nginx: file-in-usr-local usr/local/nginx/sbin/nginx
W: nginx: file-in-unusual-dir usr/local/nginx/sbin/nginx
Finished running lintian.

Пакет сформирован и должен находится в директории на уровень ниже:

Среди списка файлов мы должны увидеть пакет с нашим названием:

Описание служебных файлов

Попробуем разобраться в синтаксисе обязательных файлов, которые мы создали для выполнения сборки.

Control

Данный файл содержит основную информацию о собираемом пакете. Рассмотрим по отдельности обязательные опции и дополнительные.

Основные (без которых сборщик вернет ошибку):

Дополнительные опции файла control:

Полный перечень опций можно найти в официальном руководстве.

Rules

В данном файле мы задаем поведение при компиляции пакета. Как правило, его содержимое сводится к:

* отступы должны быть табуляциями, иначе система вернет ошибку.

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

При компиляции будет запущено три группы команд:

debian/rules clean. Выполняет чистку каталога сборки и его подготовку.
debian/rules build. Подготовка к сборке и сборка.
debian/rules binary. Установка и создание бинарного пакета.

Однако, для каждого из этапов мы можем переопределять поведение и задавать настройки (с помощью приставки override_ в файле). Рассмотрим примеры некоторых этапов и настроек.

Каталог источника

Задается с помощью параметра --sourcedirectory, например:

* в данном примере мы укажем сборщику, что брать исходные файлы нужно в каталоге src (относительно рабочего каталога). При таком определении источника, не забываем заранее создать каталог (в данном примере, mkdir src).

override_dh_auto_configure

Выполняет конфигурирование. Нам может потребоваться изменить опции на свои, например:

* обратите внимание, что если у нас исходник находится в отдельном каталоге, мы должны перейти в него и сразу (&&) запустить команду для конфигурирования. Если эти команды ввести в разных строках, то мы получим ошибку — перед выполнением каждой команды сборщик возвращается в исходную директорию.

dh_auto_build

На данном этапе выполняется сборка (make). Можно перед этим процессом закачивать исходник и распаковывать его в каталог src:

* в конечном итоге, мы запускаем тот же dh_auto_build, но с передачей дополнительной опции.

dh_auto_test

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

* для пропуска любого из этапов просто вставляем соответствующую строку с пустым перечнем действий.

dh_auto_install

На данном этапе выполняется установка пакета (make install). Рассмотрим такой пример:

* такая настройка выполнит установку, передав команде make install дополнительный параметр PG_CONFIG=/opt/pgpro/std-11/bin/pg_config. На практике, эта опция задает путь расположения конфига postgresql pro.

dh_fixperms

Задает стандартные права на файлы. Мы же можем захотеть назначить свои или отдельного владельца, например:

* в данном примере всем файлам внутри каталога будет задан владелец пользователь nginx. Обратите внимание, что мы сначала позволяем системе выставить права по своему алгоритму (dh_fixperms), после чего выполняем свою команду.

Changelog

Файл используется системой сборки для получения номера версии пакета, его ревизии, срочности и раздела. Также в него можно заносить список изменений.

Типичный пример для файла:

gentoo (0.9.12-1) unstable; urgency=medium

Пользователям Linux необходимо хотя бы приблизительно знать как происходит сборка программ из исходников. Так как вы можете столкнуться стем, что вашей программы может и не быть скомпилированной под ваш дистрибутив. Сама сборка программ не сложна, и обычно описана в файле README или INSTALL, который идет вместе с пакетами для сборки. Так что, будьте внимательны. И так, сборку из исходников мы будем разбирать на примере программы GParted. Но, для начала давайте установим необходимые утилиты – интерпретатор и компилятор, для того, что бы можно было собирать программы. Для установки необходимых утилит вводим команду:

Debian/Ubuntu

sudo apt install build-essential automake autoconf

Arch/Manjaro

sudo pacman -S base-devel --needed

Сборка программ c Github

И начнем мы с GParted, сборку или как еще называется данный процесс – компиляцию мы будем выполнять в Ubuntu 20.04 . Вы можете спросить почему именно в Ubuntu, отвечу, для Arch Linux и подобных есть AUR. Да и со сборкой программ в Arch мы разберемся чуть позже. Там можно найти практически все программы, которые существуют для Linux. Для начала нужно скачать исходники программы, для этого переходим на сайт, скачиваем, а затем распаковываем архив. Так же можно выполнить команду:

Затем переходим в папку:

Теперь заглянем в файл README и посмотрим его внимательно. Если приглядеться, то можно увидеть какие зависимости необходимы доустановить:

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

Если проблема с зависимостями у вас останется, то вы увидите об этом вывод:

После того, как вы установите все необходимые зависимости, запускаете снова “autogen.sh”. В итоге он вам скажет что можно приступать к дальнейшим действиям:

Далее запускаем “make” и затем когда “make” выполнит свою работу, запускаем “sudo make install”. Обратите внимания, в некоторых инструкциях не упоминается о том, что нужно установку программы выполнять именно от “sudo”, а именно: “sudo make install”. Из за этого у вас могут возникнуть проблемы. И так продолжаем сборку программы вводим команды:

make
sudo make install

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

После установки можно найти программу в меню установленных программ.

Сборка программ из архива

Распаковывать архив можно из терминала, а можно при помощи графического интерфейса, например программой Ark или Менеджер архивов. Тут все зависит от того, как вам удобней. Для того что бы распаковать архив в терминале, нужно выполнить определенную команду. На примере с GParted такой командой будет:

tar xzf gparted-1.1.0.tar.gz

Примечание, tar является утилитой командной строки для распаковки архивов. И так, затем переходим в папку с распакованной программой и смотрим какие там имеются файлы. Тут как раз имеются README:

Для наглядности я открою файл README в графической утилите Mousepad. Как вы можете заметить, в инструкции подробно прописано как устанавливать данную программу из исходников:

Для того что бы собрать данную программу, достаточно выполнить команды, которые прописаны в инструкции. Так как мы уже распаковали данный архив, пропускаем это шаг. Если вы не знаете как перейти в терминале в директорию программы, поясню. А если знаете, то пропустите данный шаг. Для того что бы перейти в терминале в нужную директорию, используется команда “ cd “. Например, у вас папка с программой находится по адресу “Загрузки – папка с программой”, выполняем команду:

После чего можно посмотреть что у нас имеется в данной директории введя команду “ ls “, после чего снова вводим команду “ cd ” и переходим в нужную нам директорию. Например:

Теперь приступаем к сборке программы GParted. Для этого вводим команды которые написаны в файле README.

На этом этапе установки могут возникнуть проблемы с зависимостями. По этому их необходимо установить:

После того как все необходимые зависимости были установлены, снова запускаем “./configure” и продолжаем компиляцию программы как описано выше. А именно, после запуска “./configure” запускаем “make”, а затем “sudo make install”.

Ошибки при сборке программы

Возможно, при компилировании у вас могут возникнуть проблемы с зависимостями. Для этого надо будет устанавливать необходимые пакеты. Обычно если у вас не хватает зависимостей, вы увидите во время выполнения команды ./configure ошибки. Если же вы не знаете какой зависимости не хватает, то тут выручит поисковик.

После того как вы установите необходимые зависимости, снова необходимо запустить ./configure. А может быть и так, что у вас не будет файла ./configure, попробуйте запустить другие скрипты:

Если таких скриптов вы не смогли найти, то можно выполнить последовательно следующие команды:

aclocal
autoheader
automake --gnu --add-missing --copy --foreign
autoconf -f -Wall

В случае с дистрибутивами Arch/Manjaro необходимые пакеты вы можете подгрузить используя “Менеджер программ”, Предварительно не забыв подключить репозиторий AUR:

Пример необходимых зависимостей при установки в Manjaro программы Blender. Компиляция производилась с использованием файла PKGBUILD:

Удаление программ

Если же вы захотите в будущем удалить GParted, или какую то иную программу, оставьте папку которую скачивали. Так как только в ней есть инструкция куда устанавливались те или иные пакеты. Обычно, в файле README написано как удалять установленные программы. В случае с GParted достаточно перейти в каталог с исходниками и выполнить команду:

Сборка в Arch/Manjaro (Arch Build System – ABS)

В дистрибутивах Arch и Arch подобных есть несколько способов устанавливать программное обеспечение, собственно, как и во многих других дистрибутивах. Но, в Arch имеется AUR, это пользовательский репозиторий, где лежат программы, которые не вошли в официальные репозитории. А так же существует способ собрать программу из исходников и вот тут вы можете столкнуться с тем, что вам попадется файл “PKGBUILD”. PKGBUILD это грубо говоря скрипт, который содержит инструкцию по скачиванию необходимых пакетов. Так же вместе с PKGBUILD могут быть и другие файлы, например “blender.desktop”. Вы можете открыть PKGBUILD и изменить необходимые параметры, но, это только при условии что вы знаете что делаете. Предположительно, вы уже перешли в каталог с исходниками программы, если же нет, сделать это можно командой в терминале “cd и путь к директории”. Для сборки пакета выполняем команду:

Опишу опции которые тут применяются, опция -s произвести проверку и установку зависимостей, а опция i установку самого пакета:

Читайте также: