Как собирать пакеты linux

Создайте свои собственные пакеты DEB и RPM

Мы расскажем вам, как создавать два наиболее распространенных типа пакетов Linux для распространения программного обеспечения, и вы сможете сами распространять свои собственные пакеты.

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

Мы начнем с руководство по созданию файлов DEB ((.deb) для дистрибутивов, производных от Debian — для этого мы качестве нашей базы используем Xubuntu. После этого мы подробно опишем методы, необходимые для создания пакетов RPM для использования в дистрибутивах, производных от Red Hat, и для этого мы будем использовать Fedora. Часто можно создать пакет на одном дистрибутиве, а затем установить его на родственном дистрибутиве (например, Ubuntu>Debian), но если это важно, то вам, может быть, стоит попробовать это самостоятельно.

Что касается программы, мы собираемся в качестве примера пакета, собираемого из исходного кода, использовать легковесный веб-браузер Dillo. Когда сборка выполняется из исходных текстов, в случае, если сборка не идет так, как надо, вы можете, как и обычно, поискать решения в сети интернете. Например, в случае Dillo 3.0.3, нам из-за недосмотра в архиве исходного кода пришлось для того, чтобы команды работали, перед командами сборки добавить ‘LIBS =-lX11’ .

Сборка происходит в командной строке

Ресурсы

Инсталляция (или виртуальная машина) Ubuntu и Fedora

Пошаговое описание

Шаг 01: Использование виртуальной машины

Использование средств виртуализации, таких как VirtualBox или Vmware, часто является лучшим подходом к созданию пакетов для других систем. С одной стороны, этот подход позволяет поддерживать сравнительно чистую базовую инсталляцию, сравнимой с настройками, с которыми вероятно, будут работать другие. Это также означает, что вы, используя различные дистрибутивы, можете получить коллекцию целевых систем. Кроме того, большинство средств виртуализации позволяют эмулировать различные архитектуры, и, следовательно, на 32-разрядной платформе можно запускать 64-разрядные ОС, хотя будет страдать производительность.

Шаг 02: Начинаем с нуля

Если в Ubuntu или Fedora что-то идет не так, то можно совершенно безопасно просто удалить исходный каталог и начать все заново. Обратите внимание, что инструментальные средства Debian изменяют исходный архив, так что вам придется начать с новой копии.

Часть 1: Debian

Шаг 03: Установите среду сборки

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

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

Шаг 04: Создайте ключ GPG

Если вы еще в прошлом не создали открытый ключ GPG, его необходимо создать прямо сейчас для того, чтобы можно было подписать пакеты. Вначале вводите текст gpg –gen-key. Выберите значения, устанавливаемые по умолчанию, и при запросе введите свое настоящее имя и контактные данные. Аккуратно запишите все данные, поскольку позднее нам в конфигурационном файле потребуется их точное соответствие. После этого наберите команду ls

/.gnupg для того, чтобы убедиться, что новый ключ существует (это файл имя_фамилия.gpg). Из него создайте открытый ключ:

Импортируйте его с помощью:

Шаг 05: Скачайте пакет

В этом примере мы собираемся скачать и собрать самую последнюю версию веб-браузера Dillo. Перейдите на сайт Dillo (www.dillo.org) и загрузить самый свежий архив .tar.bz. С помощью команды mkdir

/srcand создайте каталог для исходного кода и переместите в него архив.

Шаг 06: Распакуйте архив

Распакуйте архив с помощью команды tar -xjvf [имя архива].tar.bz2. Обратите внимание, что соблюдение договоренностей об именовании каталога (имяпакета-версия) является важным для наших целей, и, к счастью, пакет Dillo соответствует им. Также важно, чтобы архив с исходным кодом находится на один уровень выше каталога с исходным кодом.

Шаг 07: Настраиваем под Debian

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

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

При появлении запроса выберите один двоичный файл. Скрипт-помощник скрипт должен в каталоге с исходным кодом создать каталог с именем Debian.

Шаг 08: Откройте управляющий файл

Откройте в текстовом редакторе управляющий файл в подкаталоге Debian. Заполните раздел «Домашняя страница» (используйте Google для заполнения списка разделов программ Debian) и поля описания этого файла.

Шаг 09: Изучите имеющиеся зависимости

Вы можете изучить, какие зависимости необходимы для запуска программы, поставляемой в виде пакета. Перейдите в каталог с исходными кодами и наберите в терминале команду dpkg-depcheck -d ./configure. Если так сделать, то будут выданы ошибки, указывающие какой отсутствует пакет, необходимый для сборки программы (поставляемой отдельно). Вы можете открыть этот пакет, набрав sudo apt-get build-dep [имя пакета], и это должно помочь, если в репозитарии дистрибутива этот пакет поддерживается. Если он не поддерживается, то вам придется неоднократно запустить команду dpkg-depcheck -d ./configur и добавлять пакеты вручную, набирая команду рsudo apt-get install [имя пакета].

Шаг 10: Добавьте зависимости в управляющий файл

Когда все действия из предыдущего шага будут завершены, у вас должен быть список всех необходимых пакетов. Добавьте этот список зависимостей в раздел depends: управляющего файла. Элемент в списке должны быть разделены запятой и пробелом.

Шаг 11: Отредактируйте файл авторских прав

Попробуйте выполнить этот шаг настолько полно, насколько вы сможете, и не пропускайте его. Source: — это обычно главная страница проекта. В разделе Files: * замените информацию об авторских правах именами авторов проекта. Пример заполнения вы можете увидеть в разделе Files: debian/*, в который должна быть занесена соответствующая информация. Возможно, вам придется немного побыть детективом, чтобы найти необходимую вам информацию. Ищите в каталоге с исходными кодами файлы, такие как AUTHORS и COPYING.

Шаг 12: Отредактируйте файл журнала изменений

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

Шаг 13: Создайте пакет

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

/src/, наберите команду dpkg-buildpackage -b. Например, создайте пакет с помощью команды dpkg -I [пакет]. Для того, чтобы проверить на соответствие политики Debian, с помощью команды lintian [пакет] запустите программу Lintian. Обратите внимание, что этот инструмент, как известно, строгий, и ваше дело решать, допустимы ли для вас некоторые незначительные предупреждения о несоблюдения. Наконец, установите пакт с помощью команды sudo dpgk -i [пакет].

Часть 2: Создание пакетов RPM в Fedora

Шаг 14: Откройте управляющий файл

Перейдите в режим пользователя root, набрав для этого su. Начните с инсталляционной группы Development Tools (Инструменты разработки) в yum, а затем с помощью yum установите упаковщик gcc-c++ fedora-. Наберите команду usermod -a -G mock для того, чтобы добавить вашего пользователя в группу mock. Это позволяет нам выполнять процедуру сборки без необходимости перехода в роль пользователя root.

Шаг 15: Создайте среду сборки

Нажмите Ctrl + D для того, чтобы выйти из роли root. Введите rpmdev-setuptree для того, чтобы создать дерево каталогов (под

/rpmbuild), которое нам необходимо.

Шаг 16: Скачайте архив и переместите его в нужное место

Скачайте пакет Dillo с вебсайта Dillo и переместите архив в соответствующий каталог — наберите команду mv [имя архива]

Шаг 17: Создайте файл .spec

Дистрибутивы, созданные на основе Red Hat, такие как Fedora, используют файлы .spec для задания процесса сборки. Перейдите в каталог, в котором находятся такие файлы, с помощью команды cd

/rpmbuild/SPECS/andcreateablank.spec и создайте пустой файл .spec с помощью команды rpmdev-newspec dillo.

Шаг 18: Отредактируйте файл .spec

Наберите команду gedit dillo.spec. Заполните поля Version (Версия), Summary (Краткое содержание) Licence (Лицензия) (в данном случае — GPLv3+).В URL указывается домашняя страница проекта; в Source0 указывается адрес исходного кода. Укажите комментарии в полях BuildRequires (Требования к сборке) и Requires (Требования). Добавьте полное описание в область %description.

Шаг 19: Выполните сборку исходного кода

Если пакет вообще поддерживается в системе, запустите команду yum-builddep [имя пакета]. В противном случае, вам придется повторять команду сборки для того, чтобы получать сообщения об ошибках, или поискать документацию в архиве с исходным кодом. В каталоге SPEC наберите команду rpmbuild -ba[название пакета].spec. Если эта сборка завершится неудачно и будут выданы сообщения о дополнительных не распакованных файлах, выделите и скопируйте этот список файлов в раздел %files файла .spec и повторите команду сборки. Теперь пакет будет находиться в каталоге RPMS. Наберите команду rpm -ivh [пакет] для того, чтобы его установить. Наберите команду rpm -qa | grep [пакет] для того, чтобы убедиться, что он установлен.

Источник

Сборка и установка Linux пакетов в российских сертифицированных ОС

Введение

Ранее в статье мы описали сборку расширений для LibreOffice. Теперь мы расскажем, как наработки были перенесены на платформу Linux, а также как решались вопросы с подготовкой пакетов для российских сертифицированных операционных систем, таких как AstraLinux, ALTLinux и RedOS.

Постановка задачи и первичная реализация

После успешной реализации нашего продукта DSS для платформы Windows потребовалось перенести наработки (в том числе и расширение для LibreOffice на C++, о сборке и установке sdk которого было рассказано ранее) на платформы семейства Linux.

Состав пакета

Соответственно, необходимо определить, что мы переносим:

• служба для связи с сервером;
• драйвер для перехвата и обработки обращений к файлам;
• служба для общения и обработки информации от драйвера;
• диалоговое приложение;
• служба шифрования;
• расширение для LO.

Последний пункт легче всего интегрировать, так как сборка под Linux для него описана в нашей статье .
Что касается служб для связи сервером и для обработки обращений к файловой системе, то они написаны на .net core, а данный фреймворк с версии 3.0 также легко переносим на Linux.
Windows драйвер мы заменили на Linux Kernel Module (LKM), подробности по его созданию будут описаны в одной из дальнейших статей.

Службу шифрования также пришлось немного переписать, так как она реализована на C++.
Для переноса приложения, обеспечивающего нас диалоговым окном, написанного на WinForms, мы использовали фреймворк Avalonia. По применению и сложностям будет создана отдельная статья. Также возникла необходимость добавить запуск данного приложения через нажатие ПКМ на определённый файл. В Ubuntu в этом помог filemanager-actions (он же в ранних версиях nautilus-actions). При помощи него можно добавить практически любой сценарий обработки ПКМ, но, повторюсь, в рамках Ubuntu (как окажется далее ещё и в AltLinux).

Сборка

Теперь, когда мы определились с содержимым, для начала соберём deb пакет.
Так как у нас есть службы — их необходимо демонизировать. Для этого используем systemd.
Изначально было принято решение для сборки deb пакета использовать checkinstall. Первый пакет был собран при помощи него. Но при добавлении сборки в CI появились/возникли проблемы с окружением сборки, зависимостями и скриптами до/после установки. Поэтому было решено, что лучше это делать через fakeroot. Эти действия, по большей части, были описаны в данной статье.

Создаём отдельную директорию, содержащую инструкции для systemd, которую после перенесём в /lib/systemd/system.

Создаём директорию с содержимым, которое необходимо перенести при установке пакета.

А также создаём директорию DEBIAN, содержащую сценарии для действий перед/после установки/удаления и control, описывающий основную информацию пакета и его зависимости.
После созданного контента выполняем fakeroot dpkg-deb —build «имя пакета».

В итоге на выходе мы имеем deb пакет с содержимым.

Установка, удаление и проверка работы

Устанавливаем его командой:

При установке переносятся и запускаются три демона (приложения, работающие фоном, аналог служб Microsoft).

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

Для примера статус нашего dssservice

Далее началось тестирование пакета и выявление всех зависимостей, которые в процессе создания не были учтены. После успешной обработки всех зависимостей выяснилась одна интересная деталь. Если мы хотим подключаться по rdp к машине, то данный функционал необходимо настроить, так как по дефолту сервера для подключения по данному протоколу нет, как на Microsoft. Самым простым способом нaстройки rdp является настройка xrdp совместно с xfce4. При настройке xfce4 используется в качестве проводника Thunar и, соответственно, пункт в ПКМ, который мы добавляли через filemanager-actions, для него не добавляется. Но решение довольно быстро было найдено — находясь в домашней директории, проходим по следующему пути: и там будет лежать файл uca.xml, содержащий сценарии для ПКМ.

Разворачивание пакетов в российских сертифицированных ОС

После успешного тестирования данного пакета на Ubuntu возник вопрос о работоспособности его на других ОС, использующих dpkg, как менеджер пакетов, а, соответственно, поддерживающих .deb. А, в частности, вспомнилась отечественная разработка (импортозамещение никто не отменял) — AstraLinux.

AstraLinux

С ходу установить пакет не удалось, так как наш пакет имеет в зависимостях filemanager-actions, который мы используем для добавления пункта ПКМ в Nautilus Ubuntu. Но в AstraLinux используется файловый менеджер fly, и для добавления в него мы не будем использовать filemanager-actions, пришли к выводу, что для AstraLinux будем собирать пакет без учёта этой зависимости. А для добавления используется сценарий «имя_процесса».desktop, который добавляется в /usr/share/flyfm/actions/.

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

Cборка RPM

Следующей ОС стала ALTLinux. Она интересна тем, что имеет пакетный менеджер APT, но при этом вместо dpkg у неё используется rpm. А, следовательно, пора нам собрать наш пакет и под rpm.

Изначально попробовали сделать преобразование deb в rpm, как описано в этом мануале.

Alien достаточно мощная утилита, и с её помощью можно достаточно просто преобразовать пакет, достаточно только следовать её подсказкам и добавить недостающее (если она об этом попросит). В итоге при конвертации получили rpm пакет, но при попытке его установки вылезли зависимости, ссылок на которые изначально не было (позже расскажу, в чём была изюминка). Поэтому было принято решение собрать rpm пакет непосредственно средствами rpmbuild.

Сначала решили собирать не под ALTLinux, а под RedOs, так как со стороны бизнеса на неё более перспективные планы. RedOs основана на CentOS, поэтому сборку решили проводить в ней.

Часть с systemd остаётся без изменений, а вот Debian заменяем на файл «имя_проекта».spec, который содержит в себе всю информацию и зависимости из control, сценарии для действий перед/после установки/удаления, а так же описание содержимого пакета (непосредственно пути до того, что необходимо добавить).

После создания файла выполняем:

переносим .spec в rpmbuild/SPECS и выполняем:

после чего забираем из директории rpmbuild/RPMS созданный пакет.

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

Как оказалось, изюминка заключается в том, что при создании rpm система подтягивала дополнительные библиотеки, и ставила их в зависимость. Чтобы такого не было — необходимо в файл .spec добавить строку после описания зависимостей:

Пробуем установить и да — победа, пакет корректно устанавливается.

Для установки rpm пакета используем команду:

Для удаления (без удаления пакетов, находящихся в зависимости):

RedOs

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

В RedOs в качестве файлового менеджера используется nemo. Для добавления в него пункта в ПКМ необходимо создать файл «имя_действия».nemo_action, в котором по аналогии с файлом .desktop (для AstraLinux) будет сценарий обработки нажатия на новый пункт меню, и переместить его в

/.local/share/nemo/actions/, перезагрузить nemo и пункт появится.

ALTLinux

После успешного тестирования rpm пакета на RedOs перешли к формированию rpm пакета под
ALTLinux. По сути, необходимо скорректировать зависимости, так как для каждой оси пакеты будут иметь своё название, и снова понять, как произвести добавление пункта в ПКМ. Тут нам на помощь снова пришёл filemanager-actions, через который также можно добавить пункты в ПКМ и для Mate и Caja, которые как раз и используются в ALTLinux.

В итоге, мы собрали пакеты для основных, используемых у заказчика, ОС.

Заключение

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

Источник