Версия для печати темы

Автор: Juliette Oct 6 2008, в 11:15

С любезного согласия автора статей, Шейна Аркадия Львовича, выкладываю на форуме полный текст цикла статей по сборке RPM и DEB пакетов.

http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733224
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733236
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733257
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733287

http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733308
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733321
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733346

http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733359
http://unixforum.org/index.php?s=&showtopic=76757&view=findpost&p=733375

Ссылка на оригинал: http://tigro.info/blog/index.php?id=375

Автор: Juliette Oct 15 2008, в 11:56

Сборка пакетов. Глава 1. RPM. Часть 1. Какие RPM-пакеты бывают, и где их искать.

Не так давно у меня возникла мысль, что нужно написать пару статей о сборке пакетов в Linux, так как метод make && make install может пагубно отразиться на состоянии вашей системы. Об этом я и обмолвился в комментариях в блоге "Записки дебианщика”. Недавно мне об этом напомнили. В процессе написания, я понял что положить на бумагу свой опыт довольно сложно, поэтому у этой статьи будет две главы (сборка RPM и DEB пакетов) и несколько частей. Собирая RPM, я буду базироваться на дистрибутиве Fedora и подобным ей дистрибутивам. Относительно DEB нет смысла заострять внимание на конкретном дистрибутиве, так как разницы в пакетах (и их сборке) для Debian и Ubuntu никакой нет. Перед выходом этой статьи я специально написал http://tigro.info/blog/index.php?id=279.

Итак, вы нашли некую очень интересную программу, которой к сожалению нет в репозиториях или она не той версии. Для правильной установки (и уж тем более правильного и безболезненного удаления) нам нужно создать пакет. Почему же не следует использовать make install?

1. Это не правильно, можно сделать большую свалку из работающей системы,
2. Вам будет трудно его удалить, а если поставите в /usr, то и вообще практически не реально,
3. Вам будет также сложно его перенести на другую машину,
4. При обновлении системы он может перестать работать, так как зависимости не будут соблюдаться.

Этот список можно дополнять и дополнять.

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

1. Вы не первый кто этот пакет пытался собрать.
2. Если его нет в Fedora, то с вероятностью 95% он есть или под Mandriva, или под openSUSE, или под PLD, или под ALT Linux.

Во втором пункте перечислены все основные крупные репозитории пакетов, с которыми вам возможно придётся столкнуться. Чем же отличаются rpm-пакеты этих дистрибутивов? Да и как их отличить?

Mandriva. В своём названии пакеты обычно имеют суффикс mdv (раньше mdk) и год (так у них теперь идёт нумерация дистрибутива). Внутренний файл спецификации резко отличается от Fedora. Там используется своя конструкция для инсталляции, а именно %makeinstall_std, и конфигурации пакетов, которые используют autotools — %configure2_5x. Также используются различные макроопределения. Преобразование такого spec-файла к Федоровскому не особо простая задача. Однако некоторые пакеты преобразовываются очень просто.

openSUSE. Spec-файлы rpm-пакетов этого дистрибутива очень легко преобразовать к Федоровским. Отличительной чертой является упоминание об авторах пакета в поле %description. Есть свои макросы, а также стремление устанавливать многие пакеты в директорию /opt. Также обычно секция Release содержит большое число. Это мало о чем говорит, но если оно довольно большое, то вероятность принадлежности пакета к SUSE велика.

ALT Linux. Spec-файлы вообще ни на что не похожи. Первое, что бросается в глаза, это отсутствие секции BuildRoot и %defattr, что будет иметь довольно печальные последствия для вашего собранного пакета. Также используются свои макросы для определения каталогов и некоторых команд. Преобразовать к стандарту Fedora можно, но желательно не нужно.

PLD. Польский дистрибутив, в последнее время редко стал мне попадаться. Крайне не приятный формат spec-файла, вроде бы все сделал, а не собирается ну никак. Отличить по названию практически нельзя. Исправлять этот пакет следует в последнюю очередь.

Как искать пакеты в сети. Существует несколько поисковых сайтов по rpm-пакетам. Это http://rpmfind.net/ (в последнее время совсем бездарный) и http://rpm.pbone.net/. Однако обычно я ищу пакеты в Google. Просто вводите имя-пакета, можете указать версию и src.rpm: liferea-1.2 src.rpm. Вполне самодостаточный поиск. Если очень хочется попытаться найти пакет под Fedora, то следует добавить суффик fc: liferea-1.2 fc src.rpm.

Чем хорош Google? Тем, что он ищет пакеты не только по определённым популярным репозиториям, но и в труднодоступных местах, например, в блогах.

Для Fedora также следует поискать пакеты в специализированных репозиториях ( http://tigro.info/blog/index.php?id=279 ), может так случиться, что собирать ничего и не придётся.

Если же ничего подходящего нет, то придётся всё делать самому.

Во второй части мы рассмотрим структуру spec-файла Fedora, а также основные макроопределения spec-файлов других дистрибутивов.

Автор: Juliette Oct 15 2008, в 12:43

Сборка пакетов. Глава 1. RPM. Часть 2. Подготовка к сборке и обзор spec-файла

Сперва давайте разберёмся, что должно быть в системе для сборки rpm-пакета. Обязательно должен быть установлен пакет rpm-build. Без него не будет доступна команда rpmbuild. В зависимостях для сборки пакета в Fedora обычно не принято прописывать компилятор C/C++, по этому поводу рано или поздно вам понадобятся пакеты gcc, cpp, gcc-c++, libstdc++, libstdc++-devel, libgcc. Все остальные зависимости должен попросить сам пакет. Конечно бывают промахи, и в процессе сборки вы понимаете, что что-то упустили, но это обычно бывает довольно редко и не критично.

А что собственно из себя представляет RPM пакет? RPM-пакеты делятся на пакеты с исходниками src.rpm и пакеты готовые к установки %{arch}.rpm. В src.rpm пакетах содержится исходный тарболл (исходник программы), какие-либо другие исходники, пачти и самый главный spec-файл, который управляет процессом сборки. Все эти файлы упакованы в cpio архив. Когда вы пытаетесь войти в src.rpm пакет при помощи файлового менеджера mc вы его увидите. Также в пакете присутствует некоторые файлы с информацией.

В %{arch}.rpm-пакетах содержится cpio-архив с файлами, которые после установки разложатся по соответствующим каталогам, файлы информации и установочные скрипты скрипты.

Также вы можете встретить nosrc.rpm файлы, Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать). Внутри этого пакета находится обычно только spec-файл, а вот бинарник, который послужит исходником придется кочать с официального сайта. Под Fedora я таких пакетов не помню.

По умолчанию собирать пакеты можно только из-под root'а. В большинстве случаев это безопасно, однако всё равно есть вероятность, что корнем для секции инсталляции окажется каталог / и тогда команда rm -rf $RPM_BUILD_ROOT уничтожит все на свете. Также бывает, что "кривые" пакеты не правильно выполняют инсталляцию, и ставятся не во временный каталог, а прямо куда-нибудь в %{_prefix} (/usr). Часть файлов будет потеряна, хотя на работоспособности пакета на этой машине понятное дело это не скажется. Из-под рута вся сборка происходит в каталоге /usr/src/redhat.

Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл .rpmmacros с примерно следующим содержанием:

В секции %_topdir указывается общий каталог, в котором мы будем собирать пакеты. В нашем случае это каталог BUILD_ROOT находящийся в вашем домашнем каталоге (у меня он ashejn). Структура подкаталогов каталога BUILD_ROOT следующая.


Каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS вам необходимо создать вручную, подкаталоги каталога RPMS должны создаться автоматически во время сборки в зависимости от архитектуры.

В последнее время в Fedora принято добавлять в секцию %{release} суффикс fc6 (или fc7, или fc5). В spec-файле фигурирует опция %{?dist}, что означает если переменная %dist определена, то добавить её (в нужное место). Я советую также переопределить её в макросах rpm. Причём вы можете обозвать её как угодно, например, для ASPLinux я писал .110msiu. Только не забудьте поставить в начале точку.



Также в Fedora не принято писать сборщика пакета и вендора в spec-файлах (DAG так не думает). Все это если нужно следует определить раз и навсегда в макросах



Последним штрихом является цифровая подпись. Сгенерировать её крайне просто, командой gpg --gen-key и клавишей Enter.



Идентификатор ключа можно посмотреть командой gpg --list-key в секции pub после слеша ("/").

Основные приготовления к сборке пакетов сделаны, теперь давайте посмотрим что из себя представляет самый главный файл rpm-пакета, spec-файл. Для примера возьмём его из пакета stardict. Этот пакет хорошо подходит для обучения, так как в нем есть несколько тарболов (исходник программы, упакованный tar'ом), получается несколько пакетов и есть такая вещь, как схемы. Обычно spec-файл имеет такое же имя, как и сам пакет (stardict.spec). Однако вы можете добавить версию пакета (stardict-2.spec), удобно если вы пытаетесь поддерживать несколько веток программ. Можно даже дать какое-нибудь другое название, однако это мягко говоря не удобно.

Итак, содержимое файла stardict.spec приведено ниже. Я сразу буду вставлять комментарии после определенных секций, но если вы соедините все блоки в один и тот же файл, то получите полноценный stardict.spec. Spec-файл состоит из секций и шапки:



Summary — краткое описание пакета, Name — название, Version — версия, Release - релиз. Последним трем тегам соответствуют макроопределения %{name}, %{version}, %{release}. Их часто используют в дальнейшем. Name и Version обычно совпадает с название тарбола. Если же они отличаются, то в принципе ничего страшного, но придётся в некоторых местах spec-файла действовать нестандартными методами. Если вы собираете пакет из cvs, svn и т. д., то рекомендуется в самом начале файла сделать макроопределение %define date 20070422 (именно в таком формате, сами догадайтесь почему) и тег Release определить следующим образом: Release: %{date}cvs. В данном примере в теге Release используется %{?dist} переопределенный нами в файле .rpmmacros.

Далее, License — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется. URL — сайт программы, Group — группа, в которую будет входить данный пакет. Обычно следует прикинуть, на что этот пакет похож и посмотреть группу похожего пакета. Можно и самому придумать группу.

Source* — исходные тексты, тарболы, просто файлы. В данном примере идут два тарбола с разными программами, что делает сборку намного сложнее. Обычные файлы, например, конфигурации, могут просто копироваться в секции %install при помощи команды install. У нее простой синтаксис, install -m маска_как_у_chmod что куда . При помощи нее можно также создавать каталоги. В нашем примере она не используется, но подробнее про неё можно почитать в man.

Следует знать, что Sourсe и Source0 это одно и тоже

Patch — патчи, исправления, которые вы или кто-то другой выпустили для данного пакета. Не принято изменять исходный текст самой программы, а затем завертывать ее в тарбол. Принято накладывать заплатки. Я рекомендую делать их следующим образом. Распаковываете исходный тарбол, у нас это будет stardict-2.4.8, далее копируете stardict-2.4.8 в stardict-2.4.8.orig. После этого изменяете код в каталоге stardict-2.4.8, выходите из него и отдаете команду diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-название_патча.patch. Как видно до навания_патча идёт %{name}-%{version} пакета. В самом spec-файле обязательно следует писать название патча без макроопределений. По крайней мере версию, точно. Иначе при обновлении версии пакета, у вас и обновится версия патча, определённая макросом %{version}, а патч может быть подойдёт к новой версии программы и без каких либо изменений. Если же во время самой сборки патч не смог наложиться, то его следует либо переделать под данную версию программы, либо отключить в секции %{setup}.

BuildRoot — каталог в котором осуществляется сборка. %{_tmppath} — это макроопределение для каталога /var/tmp. Обратите внимание, на конец строки. В "%()" записывается команда к выполнению, тоже что в bash ${}. %{__id_u} ничто иное, как простой вызов команды id -u, такая запись может быть использована в spec-файлах, хотя и не особо популярна в Fedora. Одним из главных недостатков является возможность использования только одного параметра, о чем и говорит стоящий в сторонке параметр -n.



BuildRequires — секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт configure) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).

Requires — в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. RPM также автоматически прописывает зависимости perl и mono (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как rpm добавляет внутренние зависимости из собираемой программы.

В нашем примере используются конструкции Requires(post) и Requires(postun) для зависимостей в скриптах установки и удаления. В принципе достаточно и простого Requires. Здесь особенно нечего комментировать. Просто самому StarDict в процессе работы эти зависимости не нужны. Нужны они только при инсталляции и удалении.

Есть ещё несколько полезных тегов, которые здесь не используются.

Provides: название1, название2 — другие названия, помимо %{name}, на которые будет откликаться данный пакет. Удобно указывать, если вы сменили название пакета, а другие пакеты продолжают зависеть от старого названия.

Obsoletes: название1, название2 — удаление указанных пакетов при установки текущего пакета. Как бы говорится, что данный пакет замещает собой указанные (по функциональности, по набору файлов и т. п.). Можно использовать конструкцию название <|>|<=|=|=> версия. Тут вы должны сами понимать, что к чему.

Conflicts: название1, название2 — перечисляются пакеты, которые конфликтуют с текущим. Подразумевается что указанные пакеты нужно вручную удалить, перед установкой нашего. Также используются конструкции со знаками сравнения и версиями (см. выше).

Других тегов для обработки зависимостей, таких как Suggest в стандартном RPM нет. Есть ли они в других дистрибутивах, не знаю. Я видел что-то подобное в рассылке openSUSE. Нужны ли мягкие зависимости, такие как в DEB пакетах, я однозначно ответить не могу.

Epoch: число — обычно или не указывается совсем или равняется 0. Суть этого параметра вот в чем. Пусть всё наш же пакет stardict имеет версию 2.4.8, а также есть более старый 2.4.5. Так вот если %{epoch} у stardict 2.4.5 будет 1, а у 2.4.8 0, то пакет 2.4.5 будет всегда новее, чем 2.4.8. О чём при установки вам RPM и скажет. Этот параметр удобен, если вы хотите откатиться на предыдущую версию (разумеется, если вы это все выкладываете в публичный репозиторий и хватаете все YUM'ом. Для "домашних" нужд подойдёт параметр к rpm --force). Если определён тег Epoch: 0, то пакет будет иметь приоритет перед пакетом с непоределённым тегом Epoch.

BuildArch: архитектура — архитектура, под которую будет собираться наш пакет. Если эта опция не указана, то пакет соберётся под текущую архитектуру. Обычно эту опцию указывают для того, чтобы собирать пакет архитектуры noarch, то есть пакет в котором нет бинарников.

ExclusiveArch: архитектура1 архитектура2 — архитектуры, под которые данный пакет может быть собран. Обычно используется при сборки модулей к ядру.

На этом шапка заканчивается и начинаются отдельные секции.



Описание главного пакета, того, у которого будет имя %{name}


Здесь мы создаём новый пакет, название которого будет %{name}-tools. Если нужно обозвать пакет совсем по другому, то следует сделать, например, так: %package -n tools-stardict. Версия нового пакета берётся из заданного тега Version. Обратите внимание на Requires. В нём прописана зависимость на главный пакет stardict. Если бы он имел %{epoch}, то необходимо было бы обязательно указать Requires: %{name}-%{epoch}:%{version}-%{release}. Иначе вам просто не удастся установить это пакет.



Описание второго пакета


Секция %prep в ней начинается подготовка к сборке. %setup распаковывает исходники. Опция -q не показывает вывод распаковывания архива. Опция -a1 используется для распаковки %{SOURCE1}, второго тарбола внутрь(!) каталога первого тарбола. Соответственно цифра указывает на номер SOURCE. Ещё иногда используется параметр -b, тогда второй тарбол распаковывается в тот же каталог, что и первый. Соответственно если у нас один тарбол, то опции -a, -b не используются.

Если у вас первый каталог в тарболе имеет отличное от %{name}-%{version} название, то rpm не сможет войти автоматом в этот каталог. В таком случае следует немного изменить %setup. Если в архиве stardict-2.4.8.tar.bz2 первый каталог имеет название, например, просто stardict, то выглядеть это будет так: %setup -q -n %{name} -a1.

Сразу после распаковки пакета, перед %patch если нужно можно скопировать файлы, или запустить какие либо программы для изменения исходников. Допустим скопировать файл русификации, или подправить sed'ом какой-нибудь исходник. Просто вызываете здесь cp, sed или ещё что-то. В качестве корня здесь выступает каталог, в который распаковался первый тарболл (за него отвечает переменная $RPM_BUILD_DIR, но она крайне редко используется).

При помощи %patch накладываются патчи. Если вы делали патч как я писал выше, то у вас всегда будет параметр -p1. Также часто используют параметр -b .название_патча, для создания резервной копии.



Секция %build, именно здесь происходит сборка пакета. Обратите внимание на push и popd. Этими командами мы переходим и выходим из каталога второго тарбола. Именно он будет корневым каталогом после push. После команды popd мы вернёмся в каталог первого тарбола. Соответственно если у вас один исходник, то не нужно использовать эти команды.

Так как у нас две программы в одном пакете, то мы выполняем два раза концигурацию %configure и два раза make. Если пакет конфигурируется при помощи autotools, то макросом %configure запускается скрипт configure из корня распакованного тарбола. У него обычно бывает много параметров, их можно посмотреть из командной строки при помощи ./configure --help. После %configure вы можете указать нужные вам параметры. Заметьте, что вызов %configure и ./configre отличаются. В первом случае конфигуратору будут переданы правильные каталоги для инсталляции (а также стандартные параметры), во втором каталоги по умолчанию.

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

Если пакет не использует autotools, то %configure, а может и make использовтаь не нужно, для сборки прочтите файл README и INSTALL.

Когда сборка успешна закончена, в действие вступает секция %install.



Командой rm мы удаляем (если он есть) каталог предыдущих инсталляций, далее в нашем примере мы идём в каталог второго тарбола и производим установку. В качестве каталога установки через параметр DESTDIR make'у передается переменная $RPM_BUILD_ROOT, это ничто иное, как каталог указанный в теге BuildRoot. Тоже самое выполняется и для основного тарбола.

%find_lang, поиск файлов локализации. Параметром у неё является название файлов, которые будут лежать после установки в каталоге $RPM_BUILD_ROOT/usr/share/locale/*/LC_MESSAGES/*.mo. Обычно оно соответствует %{name}. Если это не так, пишите другое имя.

desktop-file-install — обработка .desktop файла для меню. Там много всяких параметров, почитайте справку. Файлы для меню, хранятся в каталоге /usr/share/applications. Их содержимое не такое сложное. В принципе, если у вас уже правильный .desktop-файл, то вызов этой команды не является обязательным.

--vendor fedora — добавляется вендора, и .desktop-файл будет иметь спереди от своего названия то, что вы укажете, в данном случае это fedora-. --delete-original — удаление старого .desktop-файла, иначе будут установлены 2. --add-category X-Red-Hat-Base добавление категории. Категории могут быть разные, самые популярные Application, Gnome, KDE, Utility, System, Audio, Internet. Именно они влияют на то, в каком подменю будет отображаться наша программа. Так как подменю не так много, то можно вычислить названия каждого просмотром .desktop-файлов программ входящих в каждое из них.

Если вы хотите добавить вашу программу в главное меню, то придётся править файл /etc/xdg/menus/applications.menu из пакета redhat-menus. В том же каталоги лежат файлы и для других меню.



Секция для удаления нашей временной установки, после сборки пакета.


Секции для установочных скриптов. Вообще их бывает несколько. %pre — выполняется перед установкой, %post — после установки, %preun — перед удалением, %postun — после удаления. В нашем примере устанавливаются и соответственно удаляются схемы Gconf. Если пакет их использует, то каждая из них должна быть перечислена (поищите их в каталоге BuildRoot/etc/gconf/schemas). Для каждого пакета могут быть свои скрипты, поэтому следует также почитать документацию. Если никаких скриптов для правильной работы не нужно, то и секции эти не следует использовать. В этих секциях можно применять bash-скрипты (впрочем как и в любых других секциях).

В секциях %files мы должны указать какие файлы должны быть упакованы в пакеты. Все файлы должны быть оговорены, в противном случае rpm-build выдаст сообщение о неупакованных файлах.

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

Для определения каталогов используются специальные макроопределения. %{_prefix} - /usr, %{_sysconfdir} - /etc, %{_bindir} - /usr/bin, %{_datadir} - /usr/share, %{_libdir} - /usr/lib, %{_lib} - /lib, %{_libexecdir} - /usr/libexec, %{_includedir} - /usr/unclude, %{_mandir} - /usr/share/man, %{_sbindir} - /usr/sbin, %{_localstatedir} - /var.



%doc помечает файлы как документацию. Третья строка копирует указанные файлы в каталог %{_datadir}/doc/%{name}-%{version}. %defattr(-,root,root) указывает, что файлы в rpm пакете должны иметь владельцем root'а, а на файлы должны быть такие же права, как и в процессе установки. Можно также указать и четвёртый параметр, для каталогов (тоже "-"). В spec-файлах от ALT Linux этой строчки нет.

Далее просто перечисляются файлы.



Тоже самое для пакета stardict-tools. Если бы он назывался tools-stardict, то %files выглядел бы так: %files -n tools-%{name}.

Последнее, что идёт в spec-файле, это %changelog. В changelog'е вы указывает изменения в пакете по сравнению с предыдущей версией. Синтаксис его примерно следующий.



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

Автор: Juliette Oct 15 2008, в 13:18

Сборка пакетов. Глава 1. RPM. Часть 2. П. 1 Сборка RPM пакета из уже установленного в системе

Иногда случается ситуация, что какой-то пакет уже установлен в системе ( может быть в очень старой системе) и очень хочется получить rpm’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.

Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта утилита написана на bash, адрес сайта http://rpmrebuild.sourceforge.net/. Для Fedora 7 я http://ftp.msiu.ru/pub/fedora/7/updates/tigro/i386/rpmrebuild-2.1-1.fc7.noarch.rpm, впрочем, вы её сможете поставить и в fc6, и в более ранние дистрибутивы.

Работать с ней крайне просто. Нужно отдать всего лишь команду:

Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.

Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это не играет роли.

Все параметры можно посмотреть при помощи



и

Автор: Juliette Oct 15 2008, в 13:51

Сборка пакетов. Глава 1. RPM. Часть 3. Макроопределения и сборка пакетов

В предыдущих частях мы познакомились со структурой spec-файла, научились распознавать пакеты по дистрибутивам, а также собирать пакеты из уже установленных. В третьей части мы рассмотрим некоторые макроопределения, научимся определять переменные, а также научимся собирать пакеты с различными параметрами и подписывать пакеты. Также будет сказано несколько слов о бекпортировании.

Запросы RPM
Сперва, давайте рассмотрим некоторые интересные команды rpm. Например, мы можем очень просто получить практически все параметры пакета. Для этого следует воспользоваться конструкцией

. Для пакета, который в системе не установлен необходимо заменить -q на -qp, а вместо "пакета" использовать имя файла неустановленного пакета.

Параметров довольно много, вот самые основные:

* %{name} — имя пакета
* %{version} — версия пакета
* %{release} — релиз пакета
* %{arch} — архитектура пакета
* %{epoch} — эпоха пакета



Из примера видно, что внутри кавычек можно писать любые символы.

Некоторые макроопределения
Теперь рассмотрим определение переменных. Например, мы собираем пакет из SVN, в данном случае обычно используется дата ревизии. В самом начале spec-файла нужно определить переменную date:



Как мы видим, за определение переменных отвечает макроопределение %define. Теперь в любом месте spec-файла мы можем использовать нашу переменную в виде %{date} (скобки не обязательны, но не будем делать так, как ALT Linux). Например, определение основных параметров будет выглядеть примерно так:



По поводу %{?dist}. Во второй части мы определили этот параметр, обратите внимание на знак вопроса "?". Он означает следующее, если переменная определена, то выводится её значение, в противном случае ничего не выводится.

Крайне популярным макроопределением является конструкция


.

Или подобная без %else. Суть проста, если условие стоящее при %if истина, то выполняется действие1, в противном случае выполняется действие2.

Допустим мы опять же собираем что-нибудь из SVN. Обычно внутри архива, если он из SVN, вместо каталога %{name}-%{version} указывают просто %{name} (архив sim-0.9.5.tar.bz2 внутри имеет каталог sim, так как финального релиза sim 0.9.5 не существует. Конечный же релиз будет иметь первым каталогом sim-0.9.5). Чтобы всякий раз не переписывать spec-файл можно сделать следующие макроопределения:



Если переменная svn не определена, то будет выполняться часть сценария после %else. Можно также использовать более строгое условие (не забудьте про кавычки):



Внутри всех секций spec-файла мы можем использовать любые команды Linux, без каких либо "наворотов", а вот в шапке файла не всё так просто. Например, нам нужно определить версию firefox для пакета (допустим epiphany) и прописать ее в секцию Requires:. Выглядеть это будет следующим образом:



Обратите внимание на то, что внешняя команда выполняется в "%()" (почти, как в bash — "$()") и в spec-файле необходимо ставить два знака % в параметрах. Таким образом можно вызывать любые команды Linux, например, для определения версии ядра.

Ещё одним популярным макроопределение является конструкция %ifarch %endif. Если архитектура соответствует указанной после %ifarch, то выполняется какое либо действие. Архитектуры бывают i386, i486, i586, i686, i?86, x86_64, и понятное дело некоторые другие, с которыми вы наверно не столкнётесь.

Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды, включая for, while, if и др.

Сборка пакета
Теперь перейдём непосредственно к сборке пакета. Исходники и патчи должны лежать в каталоге SOURCES, а spec файл в каталог SPECS (см. ч. 2). После этого нужно отдать команду:



После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты (а также пакет debuginfo, см. ниже), а в каталоге SRPMS появится исходник.

Очень часто, перед самым завершением сборки, rpmbuild выдаёт сообщение о найденных, но неупакованных файлах. Это означает, что вы просто не указали их в секции %files. Необходимо просто добавить их туда. Если же вы не хотите чтобы эти файлы попадали в пакет, то можно воспользоваться одним из следующих способов:

1. Добавить в секцию %files макроопределение %exclude путь_к_файлу/файл,
2. Добавить в начало spec-файла макроопределение %define _unpackaged_files_terminate_build 0.

Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить --clean (удалить весь мусор), --rmsource (удалить исходники из каталога SOURCE) и --target=архитектура (собрать пакет под конкретную архитектуру).

Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры я не буду, см. man rpmbuild.

По поводу пакета debuginfo. В него записывается вся отладочная информация полученная при сборки пакета. Чтобы этот пакет не собирался, необходимо в файл макросов rpm поместить следующие строки:


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

Цифровые подписи
Для подтверждения достоверности пакета, а тем более для публичного репозитория просто необходимо подписывать свои пакеты. Сперва нам необходимо сгенерировать цифровую подпись, командой gpg --gen-key. Никаких проблем у вас возникнуть не должно, выбирайте метод DSA и длину ключа не меньше 2048, впрочем мы его уже генерировали во второй части, и даже добавляли макроопределения в локальный файл rpm-макросов.

Для подписи пакета при сборки, необходимо передать rpmbuild параметр --sign. Для уже собранного пакета нужно отдать команду rpm --addsign пакет или rpm --resign пакет. Проверить подпись можно командой rpm -Kv пакет.

Бекпортирование
Это слово пришло к нам из мира Debian, где оно подразумевает адаптацию пакета из более нового Debian (либо стабильного, либо нет) в более ранний стабильный. В Fedora подобных терминов нет, так как дистрибутив обновляется раз в пол года. Однако иногда очень хочется собрать какой-либо пакет из более новой Fedora (а то и development) в более старую.

Тут может быть несколько подходов. Первый, просто пересобрать пакет, внимательно изучив зависимости. Может так сложиться, что в более новой Fedora один пакет распался на много маленьких или вообще изменил название. Возможно придётся подсобрать недостающие пакеты.

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

Оба подхода на первый взгляд просты, но могут доставить не мало мороки. С чем вы точно не столкнётесь, так это с проблемой различных макросов в spec-файлах для разных дистрибутивов Fedora. По крайней мере до выхода 5-й версии RPM.

На этом я заканчиваю описывать сборку RPM пакетов и соответственно первую главу. Во второй главе мы рассмотрим сборку DEB пакетов.

Автор: Juliette Oct 15 2008, в 14:32