GnomeOrgRu : Razrabotka/Avtopakety

Автопакет за 9 шагов

В этой статье рассказывается об основах создания автопакетов. За 9 сравнительно несложных шагов вы узнаете, как подготовить программу к установке на широкий спектр систем, напишите подготовительные, установочные скрипты и соберете простой автопакет. Результатом этой работы станет файл .package, который можно разместить на Web-сервере. Загрузив и запустив его, пользователи смогут без проблем установить вашу программу на свой компьютер.

Autopackage – это система создания пакетов, предназначенных для установки и настройки нового программного обеспечения на компьютерах Linux. Изюминка этой системы заключается в её дружелюбности к обычному пользователю, она позволяет устанавливать и удалять программы «одним кликом мыши», кроме того, она не привязана к какому-либо конкретному Linux-дистрибутиву. Фактически Autopackage работает на всех Linux-подобных системах и FreeBSD. Это было достигнуто за счет специально разработанного программного интерфейса (API) для создания установочных пакетов, скрывающего особенности разных дистрибутивов. Пакеты, созданные с использованием Autopackage, называют автопакетами.

Шаг 1. Подготовьте свою программу

Перед тем как непосредственно приступить к созданию автопакета, необходимо убедиться, что программа достаточно устойчива и готова к установке на множество разных систем. Чтобы приобрести такие качества она должна обладать некоторыми свойствами, которых в ней, возможно, еще нет. Для этого придется немного модифицировать код, но не волнуйтесь, изменения не будут масштабными. Программа будет готова к встрече с миром при выполнении всего лишь двух условий.
Во-первых, ваша программа должна быть перемещаемой, то есть должна находить файлы данных вне зависимости от того, где находится исполняемый файл, кроме того, все используемые в ней пути не должны быть намертво прописаны в исполняемом файле. Подробно узнать, как сделать приложение перемещаемым можно в руководстве по созданию перемещаемых программ. После того как ваша программа станет перемещаемой, её можно будет установить в любой каталог.
Во-вторых, все зависимости вашей программы должны быть известны и проверены. Это очень важно и требует наличия списка всех библиотек и программ, от которых зависит ваша программа. В отношении каждой зависимости попробуйте задать вопросы типа: «эта зависимость стабильна?», «широко ли доступны пакеты, удовлетворяющие эту зависимость?», «обязательно ли конечный пакет должен динамически линковать эту программу?».
Если ПО, от которого зависит ваша программа, крайне нестабильно (например, новые версии не совместимы со старыми), редко доступно в виде пакетов или его трудно найти, то его код лучше включить в проект. Альтернативно во время сборки автопакета можно попробовать статически линковать проблемную зависимость в ваш пакет. Помните: зависимости – мощный инструмент программирования, но их чрезмерное количество порождает больше проблем, нежели решает, поэтому, по возможности, постарайтесь ограничить себя в использовании сторонних библиотек.
Основным критерием вашего выбора при использовании зависимостей должна являться доступность этого ПО в виде пакетов дистрибутивов. Например, библиотека gtk+ поставляется в виде пакета со всеми распространенными ОС и, если её ещё нет в системе, у пользователя не возникнет сложностей с ее установкой, в то время как библиотека libfoo может быть доступна только в виде исходных кодов и/или только для ограниченного круга систем, ставить свою программу в зависимость от такой библиотеки будет неправильно – рядовой пользователь просто не станет собирать эту зависимость. Если программа или библиотека не доступна в виде пакетов, следует статически линковать её в пакет, или можно попробовать убедить разработчиков сделать автопакет их продукта. В последнем случае ваш автопакет будет зависеть от их автопакета, и при установке система автоматически разрешит зависимость.
Существуют случаи, когда ваша программа может работать и в отсутствии некоторых библиотек, однако их наличие позволяет использовать дополнительные функции. Тогда необходимо, чтобы эти функции можно было включать/выключать из запущенной программы, а не только во время компиляции. В программе на C/C++ обработать отсутствие какой-либо зависимости можно с помощью функции dlopen(). Однако, поскольку связку dlopen/dlsym не очень-то удобно использовать, разработчики Autopackage сделали программку relaytool, которая позволяет производить «мягкую линковку» программы. Благодаря этому можно использовать элегантную конструкцию if (libfoo_is_present) { ... }, и избавиться от кучи указателей на функции. Если вы не хотите использовать dlopen(), потому что из-за этого код выглядит хуже и сложнее читается – попробуйте relaytool.

Шаг 2. Загрузите и установите инструменты разработчика автопакетов

Вы можете загрузить их со страницы загрузки. Если ваша система использует RPM, можете загрузить инструменты в rpm-пакете, если нет – качайте тарболл – содержание одно и то же.

Шаг 3. Создайте spec-файл

Spec-файл содержит правила, которые используются при создании автопакета. Есть два способа создать его: воспользоваться специальной графической программой APSpec Generator или сгенерировать шаблон и вручную отредактировать его.
Использование специальной программы
Создатели Autopackage разработали специальную графическую программу “mkapspec”, которая делает процесс создания spec-файла очень простым. На рисунке представлена серия диалогов из этой программы. Вы можете загрузить APSpec Generator с сайта, упомянутого ранее. Для работы с этой программой у вас должен быть установлен GTK+ не ниже 2.4. Если вы решите использовать этот метод, программа поможет вам пройти рассмотренные ниже шаги 4, 5, 6 и 7.
(143 Кб)
Создание spec-файла по шаблону
Для начала в корне вашего проекта создайте каталог «autopackage», в нем будет размещен ваш spec-файл. После этого зайдите в этот каталог и запустите команду makeinstaller --mkspec > autopackage/default.apspec.in. Эта команда создаст новый spec-файл который мы будем подстраивать под вашу программу. Поскольку обычно номер версии программы хранится в конфигурационном скрипте шаблон spec-файла по умолчанию использует макрос @VERSION@, который автоматически раскрывается autoconf, так что не забудьте добавить строку «autopackage/default.apspec» в конец вашего конфигурационного скрипта.

Шаг 4. Отредактируйте верхнюю часть spec-файла

Секция [Meta] содержит информацию (метаданные) о вашей программе. По идее, в ней все должно быть понятно, тем не менее:
Остальные метаданные соответствуют описанию пакетов RPM и не должны вызывать особых трудностей.

Шаг 5. Напишите скрипты сборки

Эти скрипты очень важны для вашего пакета. Секции [BuildPrepare] и [BuildUnprepare] используются программой makeinstaller, они предназначены для компиляции вашей программы и зачистки сборочных файлов.
Если ваш проект использует утилиты autoconf/automake, то обычно бывает достаточно вызова функций prepareBuild и unprepareBuild. Если же вы используете другие системы сборки, то в этих секциях должны находиться команды, необходимые для компиляции вашей программы (например, “scons -Q” для scons –проектов или “make” для проектов использующих Makefile).
Чтобы получить более подробную информацию о написании скриптов сборки, обратитесь к GLB tutorial step 4 и Packagers Guide.

Шаг 6. Создайте скрипт import

Первая часть готова, и ваша программа скомпилирована – это хорошо. Но Autopackage необходимо знать, какие файлы помещать в пакет. Для этого и предназначена секция [Import]. Используйте команду import, чтобы импортировать файлы в пакет.
Команду import используют следующим образом:
echo (filenames...) | import
import читает файлы из стандартного ввода (STDIN). Все файлы должны быть разделены символом новой строки. Команда воспринимает групповые символы, так что вы можете ввести:
echo '*' | import
Текущим рабочим каталогом считается корневой каталог сборки ($build_root). Если вы используете prepareBuild, тогда все собранные файлы автоматически поместятся в этот корневой каталог (команда 'make install'), так что единственная вещь, которую остается сделать, – это вызвать echo '*' | import.
Если же вы не используете prepareBuild, тогда вы можете пойти одним из двух путей:
1. Реализовать команду 'make install' и убедиться, что все файлы помещаются в $build_root. После чего можно просто вызвать echo '*' | import.
2. Файлы созданные во время процесса компиляции, скорее всего, находятся в каталоге вместе с файлами, содержащими исходный код. Вы можете попробовать вручную импортировать файлы из этого каталога. Путь к исходному каталогу храниться в $source_dir.
Предположим, что для сборки своего проекта вы используете make. Make компилирует superpig.c в superpig. В исходном каталоге так же находится файл данных wai.png, используемый superpig. Тогда в вашем spec-файле должны быть следующие строки:

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

Шаг 7. Напишите скрипты prep, install и uninstall

Процесс установки любого ПО проходит через два этапа: подготовка к установке и собственно установка. Все скрипты, подготавливающие установку основного пакета и всех зависимостей, запускаются вместе, после этого последовательно запускаются все скрипы установки.
Скрипт prep нужен для подготовки пакета к установке. Этот скрипт позволяет выполнить все проверки, которые влияют на то, будет ли установлен пакет или нет. Обычно это означает проверку зависимостей, но необязательно только это. Для проверки зависимостей используют функции require и recommend. В качестве параметров эти функции получают имя RootName. Функция require прекращает процесс установки, если не может найти/установить необходимое ПО, recommend – нет. Для проверки и удовлетворения зависимостей функции require и recommend используют скелет-файлы. Разработчики позаботились и создали достаточно большую библиотеку скелет-файлов, их можно обнаружить в каталоге skeltons.
С помощью скрипта install файлы копируют на целевую систему, при этом используют специальный Autopackage API, который помогает абстрагироваться от системы. Не используйте обычные команды оболочки, такие как «cp», вместо них используйте аналоги из Autopackage API. Такой подход позволит использовать дополнительные возможности, такие как ведение логов (что позволит произвести удаление автоматически), и может решить проблемы, связанные с обеспечением совместимости между дистрибутивами. По адресу http://www.autopackage.org/api/installation.html находится список команд, которые рекомендованы к использованию при написании скрипта install. Обратите внимание, что для разных типов файлов следует использовать различные команды. Например, не следует использовать команду copyFiles для копирования файлов с расширением .desktop, вместо нее следует использовать команду installDesktop. Ниже приведен пример установки: дереву файлов, которые необходимо установить, сопоставлен установочный скрипт.

Типичные ошибки, которых следует остерегаться при написании установочного скрипта: использование общих вызовов, в то время как существуют более специфические, копирование одного и того же файла несколько раз, использование вызова installLib для библиотек, не предназначенных для использования другими программами, пропуск параметра category в вызове installDesktop (что заметно в старых версиях KDE).
Скрипт uninstall, удаляющий программу из системы, почти всегда можно оставить без изменений.

8. Скомпилируйте пакет

После создания spec-файла пришло время скомпилировать пакет. Для этого в корне проекта надо запустить команду makeinstaller. Во время её выполнения могут появляться различного рода сообщения и предупреждения, но в итоге программа должна скомпилироваться, после этого запустите make install и сгенерируйте package – файл. На этой стадии вам может понадобиться подправить spec-файл. Если собранный пакет является (или может являться) зависимостью для других пакетов, используйте опцию –b дабы дополнительно сгенерировать файлы payload и meta. Кроме этих двух файлов дополнительно будет сгенерирован XML файл репозитория, он должен быть помещен на web-сервер. Для такой программы также следует создать скелет-файл, причем пути в нем должны соответствовать файлу репозитория. Чтобы скелет-файл попал в набор разработчика следует отправить его создателям, это можно сделать в списке рассылки разработчиков. Документация по созданию скелет-файлов все ещё требует доработки, поэтому в качестве основы лучше взять похожий из набора разработчика, подробную информацию по XML файлу репозитория можно найти в Packagers Guide.

9. Протестируйте готовый пакет

Убедитесь, что ваша программа не установлена и попробуйте запустит пакет. Он установился без проблем? Программа запускается? Если да, тогда дайте протестировать пакет друзьям. Если жалоб нет, то можно публиковать пакет. Если что-то не работает пишите в список рассылки autopackage-dev-subscribe@sunsite.dk, задайте свой вопрос в форуме или чате #autopackage на сервере irc.freenode.net.

Важное замечание для разработчиков C++

Вы должны быть осторожны, если используете библиотеки QT или большое количество библиотек C++. Дело в том, что в GCC 3.4 двоичный интерфейс (ABI) приложений С++ был изменен, и поэтому программы скомпилированные с GCC 3.4, могут таинственным образом зависать на системах собранных с GCC 3.2/3.3 и наоборот. По этой причине разработчики не гарантируют, что программа будет работать на всех системах.
Тем не менее, в Autopackage существует возможность сделать автопакет для программ KDE/Qt, но это потребует большего объема работы и применения некоторых дополнительных инструментов, разработанных специально для этой цели. Полная поддержка C++ планируется в версии Autopackage 1.2. Как временную меру, разработчики предлагают включать в пакет две версии скомпилированной программы и выбирать подходящую при установке.
Если вы начинаете новый проект и хотите писать его на C++, для создания графического интерфейса можно использовать библиотеку GTKmm, она великолепно линкуется, так как является С++ оберткой для C. Примечательно, что подход с использованием оберток и привязок позаимствован из Windows, там большинство приложений распространяется вместе с привязками. В свое время он был взят на вооружение проектом Inkscape, и как результат их пакет успешно работает на всех системах.

Более подробную информацию по использованию инструментов Autopackage можно найти в руководстве по Autopackage, если после прочтения этой статьи у вас остались вопросы, прежде чем смотреть еще что-то обратитесь туда. Много полезных советов можно найти в wiki, если у вас есть опыт по созданию автопакетов, там же вы можете им поделиться. В мартовском номере (77) журнала Linux Format есть неплохая статья Грэма Моррисона «Autopackage Создаем пакет», в которой подробно рассказано, как создать автопакет для программы Kalbum. Кроме того, вас может заинтересовать пошаговое руководство по созданию пакетов), с ним вы шаг за шагом пройдете процесс создания реального пакета. Если и после этого у вас останутся вопросы, http://www.autopackage.org/community.html обратитесь к разработчикам и они попытаются ответить на них.

Итак, вы узнали, что такое автопакет и познакомились с основами его создания. Узнали, что программа гарантированно запускается на широком круге систем, если она перемещаемая и все программы от которых она зависит широко распространены и доступны в виде пакетов. Познакомились со способами создания spec-файла, описали пакет, написали скрипты сборки, подготовительные и установочные скрипты. В заключение ознакомились с важным замечанием о создании автопакетов при разработке программ на C++ и узнали где найти дополнительную информацию.