Сборка пакетов (etersoft-build-utils): различия между версиями
Нет описания правки |
Нет описания правки |
||
(не показано 18 промежуточных версий 4 участников) | |||
Строка 2: | Строка 2: | ||
Здесь рассмотрена процедура сборки [http://ru.wikipedia.org/wiki/RPM RPM-пакетов] для [[Main Page|ALT Linux]]. | Здесь рассмотрена процедура сборки [http://ru.wikipedia.org/wiki/RPM RPM-пакетов] для [[Main Page|ALT Linux]]. | ||
Это облегчённая инструкция для начинающих разработчиков, написанная с учётом использования пакета [[etersoft-build-utils]]. | Это облегчённая инструкция для начинающих разработчиков, написанная с учётом использования пакета [[etersoft-build-utils]]. Обратите внимание, что команды из состава этого пакета всегда выводят те команды, которые используются для выполнения задачи. Это может помочь для понимания сути процесса. | ||
== Первоначальная настройка == | == Первоначальная настройка == | ||
Строка 9: | Строка 8: | ||
=== С правами root === | === С правами root === | ||
Устанавливаем пакеты, необходимые для сборки: | Устанавливаем пакеты, необходимые для сборки: | ||
<pre># | <pre># epm install etersoft-build-utils</pre> | ||
Данный пакет «вытянет» по зависимостям всё остальное, обычно необходимое при сборке. | Данный пакет «вытянет» по зависимостям всё остальное, обычно необходимое при сборке. | ||
=== Под пользователем === | === Под пользователем === | ||
==== Настройки для подписи пакетов ==== | |||
<pre>%_topdir %homedir/RPM | Записываем данные о сборщике в файле ~/.rpmmacros по следующему образцу: | ||
<pre> | |||
%_topdir %homedir/RPM | |||
%_tmppath %homedir/tmp | %_tmppath %homedir/tmp | ||
%_gpg_path %homedir/.gnupg | %_gpg_path %homedir/.gnupg | ||
%_gpg_name Vitaly Lipatov <lav@altlinux. | %_gpg_name Vitaly Lipatov <lav@altlinux.org> | ||
%packager Vitaly Lipatov <lav@altlinux. | %packager Vitaly Lipatov <lav@altlinux.org> | ||
</pre> | |||
Если вы [[Процедура принятия в Team|являетесь мантейнером]], то для того, чтобы подписывать пакеты и отправлять их для сборки в Сизиф, вы должны указать адреса, под которым вы зарегистрированы в ALT Linux Team. | |||
<!--<div style="display: inline; color: red;">ВНИМАНИЕ! Сборка принципиально невозможна под учётной записью root.</div>--> | |||
==== Настройки для создания git-коммитов ==== | |||
Для того, чтобы у создаваемых вами git-коммитов был правильный пользователь (будет применяться также и для подписи тэгов сборки): | |||
$ git config --global user.email dottedmag@altlinux.org | |||
$ git config --global user.name "Mikhail Gusarov" | |||
Если у этого имени нет совпадения с gpg-ключом, можно задать его отдельно: | |||
$ git config --global user.signingkey "<ID ключа GPG для подписи тэгов>" | |||
Чтобы узнать свой <tt>user.signingkey</tt>, выполните команду | |||
$ gpg --list-secret-keys | |||
Искомое значение находится в секции sec. Его-то и следует прописать в переменную <tt>user.signingkey</tt>, предварительно снабдив символами <tt>0x</tt> | |||
В итоге должна получиться команда такого вида: | |||
$ git config --global user.signingkey 0xA26F54C8 | |||
Внесённые данные хранятся в <tt>~/.gitconfig</tt> и их всегда можно исправить. | |||
< | |||
==== Настройки для доступа к git-репозиторию и сборочнице ==== | |||
Доступ к gitery (git-сервер) и gyle (сборочный сервер) осуществляется через git. | |||
Вам нужно будет внести настройки в ''''~.ssh/config''' по образцу, заменив USERNAME на свой логин: | |||
<source lang=text> | |||
# Гитовница | |||
Host gitery | |||
HostName gitery.altlinux.org | |||
User alt_USERNAME # а не просто USERNAME! | |||
Port 222 | |||
# Сборочница | |||
Host gyle | |||
HostName gyle.altlinux.org | |||
User alt_USERNAME # а не просто USERNAME! | |||
Port 222 | |||
</source> | |||
== Сборка пакетов == | == Сборка пакетов == | ||
Образец того, как надо оформлять спек, вы можете посмотреть в пакете [http:// | Образец того, как надо оформлять спек, вы можете посмотреть в пакете [http://packages.altlinux.org/ru/Sisyphus/srpms/wcalc wcalc] или [http://packages.altlinux.org/ru/Sisyphus/srpms/gnubiff gnubiff]. Настоятельно рекомендуется обратиться к [[Spectips|документации]], а также смотреть «как это сделано в другом пакете». | ||
Получить | |||
=== Основываясь на существующем пакете === | |||
Получить git-репозиторий по названию исходного пакета можно командой | |||
$ rpmgp -g название_пакета | |||
Можно взять за основу пакет, собранный в стороннем репозитории. Поискать поможет | |||
$ rpmgp -a название | |||
Загрузить: | |||
$ rpmgp -a -d <полная строка с названием пакета> | |||
Создать git-репозиторий из пакета src.rpm: | |||
$ rpmgp -m пакет.src.rpm | |||
=== Создание репозитория пакета с нуля === | |||
Сначала создаём каталог и инициализируем в нём git-репозиторий: | |||
mkdir mypackage && cd mypackage && git init | |||
Минимально в репозитории должен присутствовать файл <tt>.gear/rules</tt> с правилами упаковки тарбола. Обычно его минимальное содержимое таково: | |||
<pre> | |||
<pre> | tar: @name@ | ||
</pre> | |||
и спек с названием <tt>mypackage.spec</tt>. | |||
Имеются [[SampleSpecs|образцы спеков]] для разных типов пакетов. | |||
На всё богатство уже существующих спеков можно любоваться здесь: https://github.com/altlinux/specs или на сайте https://packages.altlinux.org . | |||
=== Типовые действия === | === Типовые действия при сборке === | ||
rpmbb | |||
::: для сборки | ::: для сборки пакета (он будет записан в <tt>~/RPM/RPMS</tt>) | ||
< | <!-- | ||
::: для того, чтобы в пакет автоматически прописались зависимости на пакеты, необходимые при сборке | rpmbb -r | ||
::: для того, чтобы в пакет автоматически прописались зависимости на пакеты, необходимые при сборке. (см. также [[Buildreq|Использование buildreq]]) | |||
Сформированные зависимости (в строчке BuildRequires) желательно просмотреть, чтобы там не было откровенно ненужных пакетов. | |||
--> | |||
add_changelog название.spec | |||
::: для добавления строчки о данной сборке в секцию %changelog, в конце спека. После этого следует в спеке дописать комментарий, какие изменения были сделаны в данной сборке. | ::: для добавления строчки о данной сборке в секцию %changelog, в конце спека. После этого следует в спеке дописать комментарий, какие изменения были сделаны в данной сборке. | ||
== Ошибки при сборке == | == Ошибки при сборке == | ||
Для начала, нужно локализовать проблему — определить, является ли она проблемой конкретного дистрибутива/системы (например: отсутствие или неверная версия необходимых для сборки библиотек, специфика дистрибутива) или более глобальной (например: несобираемость определённой версией компилятора, ошибки в коде, несоответствие кода новым стандартам). | Для начала, нужно локализовать проблему — определить, является ли она проблемой конкретного дистрибутива/системы (например: отсутствие или неверная версия необходимых для сборки библиотек, специфика дистрибутива) или более глобальной (например: несобираемость определённой версией компилятора, ошибки в коде, несоответствие кода новым стандартам). | ||
В первом случае, поможет осуществить поиск по дистрибутиву/репозиторию, поискать решение проблемы в архивах [[Списки рассылки|почтовых рассылок]] или непосредственно попросить помощи в рассылке (sisyphus, devel, community). | В первом случае, поможет осуществить поиск по дистрибутиву/репозиторию, поискать решение проблемы в архивах [[Списки рассылки|почтовых рассылок]] или непосредственно попросить помощи в рассылке (sisyphus, devel, community). | ||
Во втором случае, стоит начать с поиска готовых решений. В открытом сообществе, считается хорошим тоном публиковать решения найденных проблем. Зачастую, поисковики выдают море полезной информации по кратко описанной в трёх-пяти словах проблеме конкретного софта или тексту ошибки, полученной при сборке. Например, запроса вида «gcc4.1 mysoftware patch» может быть достаточно для поиска патча, решающего проблему сборки с новым gcc4.1). | Во втором случае, стоит начать с поиска готовых решений. В открытом сообществе, считается хорошим тоном публиковать решения найденных проблем. Зачастую, поисковики выдают море полезной информации по кратко описанной в трёх-пяти словах проблеме конкретного софта или тексту ошибки, полученной при сборке. Например, запроса вида «gcc4.1 mysoftware patch» может быть достаточно для поиска патча, решающего проблему сборки с новым gcc4.1). | ||
Стоит также | |||
О том, как устранить отсутствие необходимых библиотек или заголовочных файлов, рассказано в следующем пункте. | Стоит также ознакомиться с другими [[Repositories|репозиториями с пакетами открытой разработки]]. Зачастую там уже сталкивались с подобными проблемами, и у них есть готовое решение (патч). | ||
<!--О том, как устранить отсутствие необходимых библиотек или заголовочных файлов, рассказано в следующем пункте.--> | |||
== Поиск пакетов == | == Поиск пакетов == | ||
Возможно при сборке вам придётся доустанавливать недостающие библиотеки. Имейте в виду, что в ALT принято называть пакеты для разработки так: libX-devel, где X — название библиотеки. | Возможно при сборке вам придётся доустанавливать недостающие библиотеки. Имейте в виду, что в ALT принято называть пакеты для разработки так: libX-devel, где X — название библиотеки. | ||
Используйте | |||
epm search название | |||
для поиска недостающего пакета или | |||
epm sf слово | |||
для поиска по файлам, содержащимся в пакетах. | |||
== Сборочная среда Hasher == | == Сборочная среда Hasher == | ||
Чтобы убедиться в том, что все зависимости правильны и сборка вашего пакета нормально пройдёт на сборочном сервере в ALT Linux, используется Hasher — среда, которая позволяет осуществить сборку пакета в «чистой» системе, куда установлены только пакеты, указанные в сборочных зависимостях. | Чтобы убедиться в том, что все зависимости правильны и сборка вашего пакета нормально пройдёт на сборочном сервере в ALT Linux, используется Hasher — среда, которая позволяет осуществить сборку пакета в «чистой» системе, куда установлены только пакеты, указанные в сборочных зависимостях. | ||
=== Под рутом === | |||
Устанавливаем hasher: | |||
# epm install hasher | |||
Перед использованием сборочной среды hasher нужно добавить специальных пользователей hasher: | |||
# hasher-useradd <ваш_логин> | |||
Далее выйдите из системы (logout) и зайдите обратно (hasher-useradd изменяет список групп, в которых состоит пользователь). | |||
<!-- См. README в /usr/share/doc/hasher-*/ --> | |||
=== Сборка === | |||
Для сборки пакета в hasher запускаем | Для сборки пакета в hasher запускаем | ||
rpmbsh -i | |||
Эта команда соберёт пакет и установит его в тестовый hasher, где его можно будет проверить. | |||
Эта команда соберёт пакет и установит его в тестовый hasher, где его можно будет проверить на работоспособность. | |||
Обратите внимание, что сборка в hasher не учитывает незакоммиченные в репозиторий изменения. Возможны следующие варианты: <tt>rpmbsh -t</tt> (запустить сборку с учётом незакоммиченных изменений) или <tt>gamend</tt> (прилепить незакоммиченные изменения к последнему коммиту. | |||
Для ускорения повторной пересборки в процессе исправления ошибок, можно не пересоздавать сборочное окружение каждый раз и действовать следующим образом. Первый раз: | |||
rpmbsh -l | |||
::: -l — не очищать окружение после сборки | |||
далее повторные сборки запускать с параметром -e: | |||
rpmbsh -e | |||
::: будет использовано уже созданное сборочное окружение. | |||
== Дополнительная документация == | == Дополнительная документация == | ||
* [[Etersoft-build-utils howto]] | |||
* Sisyphus:/devel/RpmSetup | * Sisyphus:/devel/RpmSetup | ||
* [[ОсобенностиСборкиПакетов|Описание нюансов сборки RPM-пакетов в ALT Linux и не только]] | * [[ОсобенностиСборкиПакетов|Описание нюансов сборки RPM-пакетов в ALT Linux и не только]] | ||
Строка 90: | Строка 167: | ||
* [http://docs.altlinux.ru/alt/devel/ Документация разработчика ALT Linux] | * [http://docs.altlinux.ru/alt/devel/ Документация разработчика ALT Linux] | ||
* [[Hasher|Сборка программ для ALTLinux с использованием hasher]] | * [[Hasher|Сборка программ для ALTLinux с использованием hasher]] | ||
* [http://atmsk.altlinux.org.ua/index.php?option=articles&Itemid=3&topid=9 Статьи по сборке пакетов] | <!--* [http://atmsk.altlinux.org.ua/index.php?option=articles&Itemid=3&topid=9 Статьи по сборке пакетов]--> | ||
[[Категория:Devel]] | [[Категория:Devel]] | ||
[[Категория:Packaging]] | [[Категория:Packaging]] |
Текущая версия от 18:34, 11 мая 2023
Краткая инструкция по сборке пакетов с помощью etersoft-build-utils
Здесь рассмотрена процедура сборки RPM-пакетов для ALT Linux. Это облегчённая инструкция для начинающих разработчиков, написанная с учётом использования пакета etersoft-build-utils. Обратите внимание, что команды из состава этого пакета всегда выводят те команды, которые используются для выполнения задачи. Это может помочь для понимания сути процесса.
Первоначальная настройка
С правами root
Устанавливаем пакеты, необходимые для сборки:
# epm install etersoft-build-utils
Данный пакет «вытянет» по зависимостям всё остальное, обычно необходимое при сборке.
Под пользователем
Настройки для подписи пакетов
Записываем данные о сборщике в файле ~/.rpmmacros по следующему образцу:
%_topdir %homedir/RPM %_tmppath %homedir/tmp %_gpg_path %homedir/.gnupg %_gpg_name Vitaly Lipatov <lav@altlinux.org> %packager Vitaly Lipatov <lav@altlinux.org>
Если вы являетесь мантейнером, то для того, чтобы подписывать пакеты и отправлять их для сборки в Сизиф, вы должны указать адреса, под которым вы зарегистрированы в ALT Linux Team.
Настройки для создания git-коммитов
Для того, чтобы у создаваемых вами git-коммитов был правильный пользователь (будет применяться также и для подписи тэгов сборки):
$ git config --global user.email dottedmag@altlinux.org $ git config --global user.name "Mikhail Gusarov"
Если у этого имени нет совпадения с gpg-ключом, можно задать его отдельно:
$ git config --global user.signingkey "<ID ключа GPG для подписи тэгов>"
Чтобы узнать свой user.signingkey, выполните команду
$ gpg --list-secret-keys
Искомое значение находится в секции sec. Его-то и следует прописать в переменную user.signingkey, предварительно снабдив символами 0x
В итоге должна получиться команда такого вида:
$ git config --global user.signingkey 0xA26F54C8
Внесённые данные хранятся в ~/.gitconfig и их всегда можно исправить.
Настройки для доступа к git-репозиторию и сборочнице
Доступ к gitery (git-сервер) и gyle (сборочный сервер) осуществляется через git. Вам нужно будет внести настройки в '~.ssh/config по образцу, заменив USERNAME на свой логин:
# Гитовница
Host gitery
HostName gitery.altlinux.org
User alt_USERNAME # а не просто USERNAME!
Port 222
# Сборочница
Host gyle
HostName gyle.altlinux.org
User alt_USERNAME # а не просто USERNAME!
Port 222
Сборка пакетов
Образец того, как надо оформлять спек, вы можете посмотреть в пакете wcalc или gnubiff. Настоятельно рекомендуется обратиться к документации, а также смотреть «как это сделано в другом пакете».
Основываясь на существующем пакете
Получить git-репозиторий по названию исходного пакета можно командой
$ rpmgp -g название_пакета
Можно взять за основу пакет, собранный в стороннем репозитории. Поискать поможет
$ rpmgp -a название
Загрузить:
$ rpmgp -a -d <полная строка с названием пакета>
Создать git-репозиторий из пакета src.rpm:
$ rpmgp -m пакет.src.rpm
Создание репозитория пакета с нуля
Сначала создаём каталог и инициализируем в нём git-репозиторий:
mkdir mypackage && cd mypackage && git init
Минимально в репозитории должен присутствовать файл .gear/rules с правилами упаковки тарбола. Обычно его минимальное содержимое таково:
tar: @name@
и спек с названием mypackage.spec.
Имеются образцы спеков для разных типов пакетов.
На всё богатство уже существующих спеков можно любоваться здесь: https://github.com/altlinux/specs или на сайте https://packages.altlinux.org .
Типовые действия при сборке
rpmbb
- для сборки пакета (он будет записан в ~/RPM/RPMS)
add_changelog название.spec
- для добавления строчки о данной сборке в секцию %changelog, в конце спека. После этого следует в спеке дописать комментарий, какие изменения были сделаны в данной сборке.
Ошибки при сборке
Для начала, нужно локализовать проблему — определить, является ли она проблемой конкретного дистрибутива/системы (например: отсутствие или неверная версия необходимых для сборки библиотек, специфика дистрибутива) или более глобальной (например: несобираемость определённой версией компилятора, ошибки в коде, несоответствие кода новым стандартам). В первом случае, поможет осуществить поиск по дистрибутиву/репозиторию, поискать решение проблемы в архивах почтовых рассылок или непосредственно попросить помощи в рассылке (sisyphus, devel, community).
Во втором случае, стоит начать с поиска готовых решений. В открытом сообществе, считается хорошим тоном публиковать решения найденных проблем. Зачастую, поисковики выдают море полезной информации по кратко описанной в трёх-пяти словах проблеме конкретного софта или тексту ошибки, полученной при сборке. Например, запроса вида «gcc4.1 mysoftware patch» может быть достаточно для поиска патча, решающего проблему сборки с новым gcc4.1).
Стоит также ознакомиться с другими репозиториями с пакетами открытой разработки. Зачастую там уже сталкивались с подобными проблемами, и у них есть готовое решение (патч).
Поиск пакетов
Возможно при сборке вам придётся доустанавливать недостающие библиотеки. Имейте в виду, что в ALT принято называть пакеты для разработки так: libX-devel, где X — название библиотеки.
Используйте
epm search название
для поиска недостающего пакета или
epm sf слово
для поиска по файлам, содержащимся в пакетах.
Сборочная среда Hasher
Чтобы убедиться в том, что все зависимости правильны и сборка вашего пакета нормально пройдёт на сборочном сервере в ALT Linux, используется Hasher — среда, которая позволяет осуществить сборку пакета в «чистой» системе, куда установлены только пакеты, указанные в сборочных зависимостях.
Под рутом
Устанавливаем hasher:
# epm install hasher
Перед использованием сборочной среды hasher нужно добавить специальных пользователей hasher:
# hasher-useradd <ваш_логин>
Далее выйдите из системы (logout) и зайдите обратно (hasher-useradd изменяет список групп, в которых состоит пользователь).
Сборка
Для сборки пакета в hasher запускаем
rpmbsh -i
Эта команда соберёт пакет и установит его в тестовый hasher, где его можно будет проверить на работоспособность.
Обратите внимание, что сборка в hasher не учитывает незакоммиченные в репозиторий изменения. Возможны следующие варианты: rpmbsh -t (запустить сборку с учётом незакоммиченных изменений) или gamend (прилепить незакоммиченные изменения к последнему коммиту.
Для ускорения повторной пересборки в процессе исправления ошибок, можно не пересоздавать сборочное окружение каждый раз и действовать следующим образом. Первый раз:
rpmbsh -l
- -l — не очищать окружение после сборки
далее повторные сборки запускать с параметром -e:
rpmbsh -e
- будет использовано уже созданное сборочное окружение.
Дополнительная документация
- Etersoft-build-utils howto
- Sisyphus:/devel/RpmSetup
- Описание нюансов сборки RPM-пакетов в ALT Linux и не только
- Сборка пакетов RPM и DEB в других системах.
При сборке пакетов сверяйтесь со следующей документацией: