Spec — различия между версиями

Материал из ALT Linux Wiki
Перейти к: навигация, поиск
(Url)
(Patch: mention autopatch directive)
 
(не показаны 72 промежуточные версии 17 участников)
Строка 1: Строка 1:
 +
[[Категория:RPM spec]]
 +
 
{{Stub}}
 
{{Stub}}
  
В данном документе концентрируются отличия Sisyphus RPM от остальных веток RPM, влияющие на содержание spec-файлов.
+
== Работа с upstream-исходниками ==
  
== <tt>Version</tt> ==
+
Если имя пакета, имя архива с upstream-исходным кодом и имя директории, содержащейся в архиве, не совпадают, не следует перепаковывать архив, чтобы угодить действиям по умолчанию в RPM. Вместо этого стоит указать все названия в spec-файле явно:
  
Версия upstream-кода. В случае упаковки промежуточной версии (1.0-rc1, 1.0-20080105) версия среза упаковывается в поле [[#Release|Release]].
+
%define origname imms
 +
 +
Name: xmms-%origname
 +
#...
 +
 +
Url: <nowiki>http://www.luminal.org/phpwiki/index.php/IMMS</nowiki>
 +
Source: <nowiki>http://www.luminal.org/files/%origname/%origname-%version.tar.bz2</nowiki>
 +
 +
# if we had a published package with original name
 +
Obsoletes: %origname
 +
 +
%prep
 +
%setup -n %origname-%version
  
== <tt>Release</tt> ==
+
Разумеется, это всё относится только к пакетам, собираемым не с помощью [[Gear]].
  
Для пакетов Sisyphus поле <tt>Release</tt> должно иметь вид в простых случах — <tt>altN</tt>, а в сложных (см. ниже) — <tt>altN[суффикс]</tt>.
+
== Включение/выключение подпакетов ==
 +
 
 +
Иногда определённые подпакеты нужно собирать только в особых ситуациях (например, статические библиотеки или вариант для bootstrap новой архитектуры). Это делается следующим образом:
 +
 
 +
# По умолчанию будет выключено.
 +
# Одноразово в командной строке rpm/rpmbuild включается с помощью --enable=static
 +
%def_disable static
 +
[...]
 +
# Если заодно необходимо передавать опцию --(disable|enable)-static в configure,
 +
# то можно написать следующую конструкцию.
 +
# (В разных случаях она будет раскрываться в разные значения.)
 +
%configure %{subst_enable static}
 +
[...]
 +
%if_enabled static
 +
%files devel-static
 +
[...]
 +
%endif
 +
 
 +
== Проверка плагинов ==
 +
У нас в rpm-build >= 4.0.4-alt100.91 есть механизм проверки плагинов,
 +
который используется в разных пакетах.  Вот, например, ldv когда-то применил
 +
его для irssi, выглядит это так (%_bindir/irssi можно прелоадить,
 +
потому что он PIE):
 +
 
 +
export RPM_LD_PRELOAD_irssi=%buildroot%_bindir/irssi
 +
export RPM_FILES_TO_LD_PRELOAD_irssi='%irssi_modules_dir/lib*.so %perl_vendor_autolib/Irssi/*.so'
 +
export RPM_LD_PRELOAD_libperl_core='%buildroot%irssi_modules_dir/libperl_core.so'
 +
export RPM_FILES_TO_LD_PRELOAD_libperl_core='%irssi_modules_dir/libfe_perl.so %perl_vendor_autolib/Irssi/*.so'
 +
%set_verify_elf_method strict
 +
 
 +
== Version ==
 +
 
 +
Версия upstream-кода.
 +
 
 +
В случае упаковки промежуточной версии ({{pkg|1.0-rc1}}, {{pkg|1.0-20080105}}) версия среза упаковывается в поле [[#Release|Release]]: 1.0rc [http://lists.altlinux.org/pipermail/devel/2007-September/144131.html лексикографически круче] 1.0, вследствие чего для нормального обновления 1.0rc до 1.0 придётся
 +
* добавлять <tt>Serial: 1</tt>,
 +
* оформлять как {{pkg|1.0rel}} или
 +
* ждать поднятия версии апстримом.
 +
Чтобы избежать таких сложностей в случае, когда разработчик апстрима именует промежуточные версии без учёта лексикографического порядка сортировки, в номер версии в нужном месте добавляем свой суффикс «.0». Например, в случае планов апстрима после {{pkg|1.0}} выпустить {{pkg|1.0.1}}, для промежуточной у апстрима версии {{pkg|1.0.1-rc1}} в спеке пишем {{pkg|1.0.0.1-rc1}}.
 +
 
 +
==== Расшифровка именования промежуточных версий ====
 +
На [https://lists.altlinux.org/pipermail/devel/2019-May/207886.html примере] {{pkg|libxml2 2.9.4.0.12.e905-alt1}}:
 +
* у апстрима {{pkg|v2.9.4-12-ge905f08}} — это вывод <code>git describe e905f08</code>;
 +
* «12» - это количество коммитов, отделяющих коммит «e905f08» от «v2.9.4»;
 +
* «.0» - это суффикс, добавленный к версии {{pkg|2.9.4}}, чтобы получившийся результат {{pkg|2.9.4.0}} был гарантированно меньше любой версии, выпущенной после {{pkg|2.9.4}};
 +
* «e905» получен с помощью <code>git describe --abbrev=1 e905f08</code>;
 +
* «2.9.4.0.12.e905» написан по мотивам вывода утилиты <code>git-version-gen</code> из <code>gnulib</code>.
 +
 
 +
== Release ==
 +
 
 +
Для пакетов Sisyphus поле {{term|Release}} должно иметь вид в простых случаях — {{pkg|altN}}, а в сложных (см. ниже) — {{pkg|altN[суффикс]}}.
  
 
Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки:
 
Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки:
  
* 1.0-alt1
+
* {{pkg|1.0-alt1}}
* 1.0-alt2
+
* {{pkg|1.0-alt2}}
* 1.0-alt3
+
* {{pkg|1.0-alt3}}
* 1.1-alt1
+
* {{pkg|1.1-alt1}}
* 1.2-alt1
+
* {{pkg|1.2-alt1}}
* 1.2-alt2
+
* {{pkg|1.2-alt2}}
 
* …
 
* …
  
 
Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов.
 
Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов.
 +
 +
<div id="intermediate"></div>
  
 
=== Промежуточные upstream-релизы ===
 
=== Промежуточные upstream-релизы ===
  
При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле <tt>Release</tt>:
+
При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле {{term|Release}}:
* 1.0-alt1.r6543
+
* {{pkg|1.0-alt1.r6543}}
* 1.0-alt1.20080101
+
* {{pkg|1.0-alt1.20080101}}
* 1.0-alt1.rc1
+
* {{pkg|1.0-alt1.rc1}}
* 1.0-alt1.rc2
+
* {{pkg|1.0-alt1.rc2}}
 +
* {{pkg|1.0-alt1.gitda39a3ee}}<ref>для ссылки на коммит удобен {{cmd|git describe}}</ref>
 +
 
 +
Если система контроля версий не предоставляет линейной нумерации коммитов, то с каждым новым срезом нужно увеличивать номер релиза:
 +
 
 +
* {{pkg|1.0-alt1.hg.da39a3ee}}
 +
* {{pkg|1.0-alt2.hg.0d3255bf}}
 +
* {{pkg|1.0-alt3.hg.fef95601}}
  
 
При первой сборке финального upstream-релиза следует поднять номер релиза пакета:
 
При первой сборке финального upstream-релиза следует поднять номер релиза пакета:
  
* 1.0-alt2
+
* {{pkg|1.0-alt1.gitda39a3ee}}
 +
* {{pkg|1.0-alt2.gitd06f1866}}
 +
* {{pkg|1.0-alt3}}
  
Использовать релиз <tt>alt0</tt> запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами.
+
Использовать релиз {{pkg|alt0}} запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с [[Backports Policy|бэкпортами]] (в отличие от, например, {{pkg|alt0.1}}, который при бэкпорте для p7 становится {{pkg|alt0.0.M70P.1}}).
  
 
=== Бэкпорты ===
 
=== Бэкпорты ===
Строка 41: Строка 116:
 
{{Main|BackportsPolicy#Правила нумерации релизов}}
 
{{Main|BackportsPolicy#Правила нумерации релизов}}
  
== <tt>Epoch</tt> ==
+
== Epoch ==
  
 
Поле Epoch используется тогда, когда по какой-то причине (странное поведение upstream-а, ошибочная заливка пакета или похожие форс-мажорные обстоятельства) требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля <tt>Epoch</tt> увеличивается на единицу по сравнению с предыдущим (отсутствие поля <tt>Epoch</tt> эквивалентно значению 0), версия и релиз устанавливаются в нужное значение.
 
Поле Epoch используется тогда, когда по какой-то причине (странное поведение upstream-а, ошибочная заливка пакета или похожие форс-мажорные обстоятельства) требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля <tt>Epoch</tt> увеличивается на единицу по сравнению с предыдущим (отсутствие поля <tt>Epoch</tt> эквивалентно значению 0), версия и релиз устанавливаются в нужное значение.
  
Будьте осторожны - в имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM-ов с одинаковыми Version и Release и разными Epoch.
+
Будьте осторожны — в имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM-ов с одинаковыми Version и Release и разными Epoch.
  
 
Устаревшим синонимом поля <tt>Epoch</tt> является <tt>Serial</tt>.
 
Устаревшим синонимом поля <tt>Epoch</tt> является <tt>Serial</tt>.
  
== <tt>Summary</tt> ==
+
== Summary ==
  
Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки.
+
Cодержит краткое описание пакета. Оно выводится, например, при поиске пакета через <tt>apt-cache search</tt>. Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки.
  
== <tt>License</tt> ==
+
== License ==
  
* Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL).
+
* Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять «or any later version», а также менять указанные версии или смешивать GPL и LGPL).
* Несвободные лицензии должны быть указаны как "distributable"
+
* Несвободные лицензии должны быть указаны как «distributable»
  
При указании лицензии рекомендуется пользоваться макросами из пакета <tt>rpm-build-licenses</tt>.
+
При указании лицензии рекомендуется пользоваться макросами из пакета {{pkg|rpm-build-licenses}}, добавив его в список BuildRequires.
  
Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в <tt>/usr/share/license</tt> (пакет <tt>common-licenses</tt>). Если же таковой файл там присутствует, то достаточно указать название лицензии в тэге пакета.
+
Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в <tt>/usr/share/license</tt> (пакет {{pkg|common-licenses}}). Если же таковой файл там присутствует, то достаточно указать название лицензии в тэге пакета.
  
 
Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно.
 
Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно.
  
== <tt>Group</tt> ==
+
С ноября 2019 года в {{pkg|sisyphus_check}} в режиме предупреждения [https://lists.altlinux.org/pipermail/devel/2019-November/209050.html включена] проверка на соответствие содержимого тега <tt>License:</tt> классификации SPDX (соответственно дополнено содержимое пакета {{pkg|common-licenses}}).
 +
 
 +
== Group ==
  
 
Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>.
 
Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>.
  
== <tt>Url</tt> ==
+
== Url ==
  
В тэге <tt>Url</tt> настоятельно рекомендуется указывать действующий URL домашней страницы проекта, либо если таковой нет - любого другого места, где можно получить архив с исходным кодом.
+
В тэге <tt>Url</tt> настоятельно рекомендуется указывать действующий URL домашней страницы проекта, либо если таковой нет — любого другого места, где можно получить архив с исходным кодом.
  
 
Рекомендуется периодически проверять адреса в своих пакетах на предмет того, что они действующие, и проект не переехал (даже если по старому адресу стоит перенаправление на новый, имеет смысл исправить содержимое тэга).
 
Рекомендуется периодически проверять адреса в своих пакетах на предмет того, что они действующие, и проект не переехал (даже если по старому адресу стоит перенаправление на новый, имеет смысл исправить содержимое тэга).
Строка 77: Строка 154:
 
  rpmurl -c пакет.spec
 
  rpmurl -c пакет.spec
  
== <tt>Source</tt> ==
+
== Source ==
  
В <tt>Source</tt> настоятельно рекомендуется указывать действующий URL до архива исходного кода относительно тэга <tt>Url</tt>:
+
Если сборка производится без использования {{prg|gear}}, то в {{term|Source}} настоятельно рекомендуется указывать действующий URL архива исходного кода относительно тэга {{term|Url}}:
 
  Source: %url/some/thing/%name-%version.tar.bz2
 
  Source: %url/some/thing/%name-%version.tar.bz2
Формат <tt>Source</tt> для известных хостингов:
+
Формат {{term|Source}} для известных хостингов:
 
  # иногда проект называется не так, как пакет, будьте внимательны
 
  # иногда проект называется не так, как пакет, будьте внимательны
  Source: http://dl.sourceforge.net/%name/%name-%version.tar.bz2
+
  Source: <nowiki>http://dl.sourceforge.net/%name/%name-%version.tar.bz2</nowiki>
  Source: http://download.berlios.de/%name/%name-%version.tar.bz2
+
  Source: <nowiki>http://download.berlios.de/%name/%name-%version.tar.bz2</nowiki>
 +
 
 +
Если тарбол формируется из {{prg|[[gear]]}}-репозитория, то в {{term|Source}} указывается имя файла согласно прописанному в {{path|.gear/rules}}, например
 +
Source: %name-%version.tar
  
 
Если исходники берутся из системы контроля версий, то рекомендуется указывать в комментарии рядом команду для получения данного снапшота:
 
Если исходники берутся из системы контроля версий, то рекомендуется указывать в комментарии рядом команду для получения данного снапшота:
Строка 90: Строка 170:
 
  Source: %name.tar.bz2
 
  Source: %name.tar.bz2
  
== <tt>Patch</tt> ==
+
== Patch ==
  
 
Рекомендуемое именование патчей:
 
Рекомендуемое именование патчей:
* <tt>NAME-VERSION-ORIGIN-WHAT.patch</tt>, где
+
* {{term|NAME-VERSION-ORIGIN-WHAT.patch}}, где
** <tt>NAME</tt> и <tt>VERSION</tt> — имя и версия пакета, для которого сделан патч,
+
** {{term|NAME}} и {{term|VERSION}} — имя и версия пакета, для которого сделан патч,
** <tt>ORIGIN</tt> — аббревиатура источников патча (обычно дистрибутивов),
+
** {{term|ORIGIN}} — аббревиатура источников патча (обычно дистрибутивов),
** <tt>WHAT</tt> — краткое описание патча.
+
** {{term|WHAT}} — краткое описание патча.
  
Если патч образован из нескольких частей, полученных из разных источников, <tt>ORIGIN</tt> должен включать аббревиатуры всех источников. Аббревиатура ALT Linux / Sisyphus — <tt>alt</tt>. Для патчей, полученных на основе системы контроля версий, <tt>ORIGIN</tt> должен включать в себя дату или номер ревизии.
+
Если патч образован из нескольких частей, полученных из разных источников, {{term|ORIGIN}} должен включать аббревиатуры всех источников. Аббревиатура ALT Linux / Sisyphus — {{term|alt}}. Для патчей, полученных на основе системы контроля версий, {{term|ORIGIN}} должен включать в себя дату или номер ревизии.
  
 
В описании патча рекомендуется пользоваться следующими сокращениями:
 
В описании патча рекомендуется пользоваться следующими сокращениями:
* <tt>makefile</tt> — патчи, затрагивающие исключительно <tt>Makefile*</tt>,
+
* {{term|makefile}} — патчи, затрагивающие исключительно {{path|Makefile*}},
* <tt>bound</tt> — проверки на границы (буфера, целых чисел и т. д.),
+
* {{term|bound}} — проверки на границы (буфера, целых чисел и т. д.),
* <tt>config</tt> — патчи, затрагивающие исключительно конфигурационные файлы,
+
* {{term|config}} — патчи, затрагивающие исключительно конфигурационные файлы,
* <tt>configure</tt> — патчи, затрагивающие исключительно <tt>configure*</tt>,
+
* {{term|configure}} — патчи, затрагивающие исключительно {{path|configure*}},
* <tt>doc</tt> — патчи, затрагивающие исключительно документацию,
+
* {{term|doc}} — патчи, затрагивающие исключительно документацию,
* <tt>fixes</tt> — кумулятивные патчи/исправления по надёжности и/или безопасности,
+
* {{term|fixes}} — кумулятивные патчи/исправления по надёжности и/или безопасности,
* <tt>format</tt> — патчи на использование форматирования строк (типа <tt>printf</tt>),
+
* {{term|format}} — патчи на использование форматирования строк (типа {{term|printf}}),
* <tt>install</tt> — патчи на выполнение <tt>make install</tt> непривилегированным пользователем,
+
* {{term|install}} — патчи на выполнение {{cmd|make install}} непривилегированным пользователем,
* <tt>linux</tt> — патчи для портирования По на Linux,
+
* {{term|linux}} — патчи для портирования По на Linux,
* <tt>man</tt> — патчи, затрагивающие исключительно man-страницы,
+
* {{term|man}} — патчи, затрагивающие исключительно man-страницы,
* <tt>texinfo</tt> — патчи, затрагивающие исключительно документацию в формате texinfo,
+
* {{term|texinfo}} — патчи, затрагивающие исключительно документацию в формате {{term|texinfo}},
* <tt>tmp</tt> — патчи, предназначенные для решения различных вопросов, связанных с временными файлами,
+
* {{term|tmp}} — патчи, предназначенные для решения различных вопросов, связанных с временными файлами,
* <tt>vitmp</tt> — патчи для поддержки <tt>vitmp(1)</tt>
+
* {{term|vitmp}} — патчи для поддержки {{term|vitmp(1)}}
* <tt>warnings</tt> — патчи, исправляющие предупреждения, выданные компилятором
+
* {{term|warnings}} — патчи, исправляющие предупреждения, выданные компилятором
 +
 
 +
<small>(начиная с rpm-build 4.0.4-alt133)</small> Все патчи, описанные в основной секции spec-файла, можно в секции [[#%prep|%prep]] применить директивой %autopatch. %autopatch принимает опции -p и -F, аналогичные таким же опциям директивы %patch.
  
== <tt>Requires</tt>, <tt>PreReq</tt> ==
+
== Requires, PreReq ==
  
 
При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так:
 
При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так:
 
  Requires: %name = %epoch:%version-%release
 
  Requires: %name = %epoch:%version-%release
  
== <tt>BuildRequires</tt>, <tt>BuildPreReq</tt> ==
+
=== Requires ===
 +
 
 +
Используется для обозначения зависимостей между пакетами, которые необходимо удовлетворить для нормальной работы программ, не входящих в пакет с создаваемым/корректируемым спеком.
 +
Requires:  java >= 1.6
 +
 
 +
== BuildRequires, BuildPreReq, BuildRequires(pre) ==
  
 
Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>.
 
Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>.
Строка 129: Строка 216:
 
* указанием дополнительных зависимостей в <tt>BuildPreReq</tt> и периодическим их обновлением.
 
* указанием дополнительных зависимостей в <tt>BuildPreReq</tt> и периодическим их обновлением.
  
== <tt>BuildRoot</tt> ==
+
При необходимости наличия в окружении, где выполняется раскрытие макросов для создания src.rpm, дополнительных пакетов {{pkg|rpm-macros-*}} либо {{pkg|rpm-build-*}} их следует указать тэгом <tt>BuildRequires(pre)</tt>. Злоупотреблять им не следует (затрудняет [[bootstrap|бутстрапы]]); критерий необходимости именно этой формы -- ошибка (не предупреждение!) при попытке выполнить в недостаточном окружении команду вида
 +
 
 +
rpm -bs --nodeps этот.spec
 +
 
 +
Обратите внимание, что для {{cmd|gear-rpm}} ограничения иные и этот критерий неприменим.
 +
 
 +
== BuildArch ==
 +
Используется для указания архитектуры (под)пакета.  Возможные значения:
 +
* <tt>x86_64</tt>
 +
* <tt>%ix86</tt><ref>См. {{cmd|rpm --eval %ix86}}</ref> или индивидуально <tt>i386</tt>, <tt>i586</tt>, <tt>i686</tt>...
 +
* <tt>noarch</tt>
 +
В случае указания среди тегов основного пакета определяет архитектуру всех подпакетов; для индивидуальных подпакетов — как правило, с данными, документацией либо скриптами — допускается указание только <tt>noarch</tt>, и то при условии использования {{pkg|rpm-4.0.4-alt94}} или более новой сборки.
 +
 
 +
== BuildRoot ==
  
 
Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно.
 
Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно.
  
== <tt>BuildHost</tt> ==
+
== BuildHost ==
  
 
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>.
 
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>.
  
== <tt>Prefix</tt> ==
+
== Prefix ==
  
 
Тэг <tt>Prefix</tt> в Sisyphus RPM не нужен, он самостоятельно устанавливается в <tt>/usr</tt>.
 
Тэг <tt>Prefix</tt> в Sisyphus RPM не нужен, он самостоятельно устанавливается в <tt>/usr</tt>.
  
== <tt>%description</tt> ==
+
== Conflicts ==
 +
 
 +
Применяется для указания наличия конфликта (обязательно в случае файлового/RPC и желательно в случае существенного смыслового) между данным пакетом и указываемым.  Не надо ставить конфликты на то, чего ещё нет и о чём, соответственно, ничего не известно.  Достаточно проставить односторонне.
 +
 
 +
== Provides ==
 +
 
 +
Используется для указания того факта, что данный пакет предоставляет функциональность иного (переименованного устаревшего названия, широко известного по другим дистрибутивам либо же виртуального).  Следует применять только в случае реальной необходимости и, как правило, в форме
 +
<tt>Provides: something = %version-%release</tt>
 +
 
 +
При переименовании пакета обязательно сочетается с <tt>Obsoletes:</tt>.
 +
 
 +
== Obsoletes ==
 +
 
 +
Перечисляет пакеты/версии, объявленные устаревшими.  Обычно применяется при переименовании пакета в сочетании с <tt>Provides:</tt> и с указанием версии, меньшей или равной последней известной версии пакета под старым названием:
 +
 +
Name: someproject
 +
Version: 1.0
 +
Release: alt1
 +
# ...
 +
Provides: oldproject = %version-%release
 +
Obsoletes: oldproject <= 0.9.1
 +
 
 +
(Примечание: [[Реагирует ли сборочница на переименование пакетов]].)
 +
 
 +
== %description ==
 +
 
 +
Здесь указывается описание пакета. Данное описание учитывается при поиске пакета через <tt>apt-cache search</tt> и полностью выводится во время просмотра информации о пакете при помощи <tt>apt-cache show имя_пакета</tt>.
  
 
Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику:
 
Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику:
* Описание программы или инструмента должно содержать их функционал, а не особенности реализации (язык, используемые библиотеки и т.д.)
+
* Описание программы или инструмента должно содержать их функционал, а не особенности реализации (язык, используемые библиотеки и т. д.)
* Описание библиотеки должно содержать язык программирования, для которого предназначена библиотека и решаемую задачу
+
* Описание библиотеки должно содержать язык программирования, для которого предназначена библиотека, и решаемую задачу
* ...
+
*
  
== <tt>%prep</tt> ==
+
Длина каждой строки не должна превышать 72 символа ради читабельности в различных случаях.
  
=== <tt>%setup</tt> ===
+
== %prep ==
 +
 
 +
=== %setup ===
 +
 
 +
Макрос %setup распаковывает исходный код перед компиляцией.
  
 
Конструкция <tt>%setup</tt> в Sisyphus RPM использует флаг <tt>-q</tt> (quiet) по умолчанию. Для включения отладочного вывода используйте флаг <tt>-v</tt>.
 
Конструкция <tt>%setup</tt> в Sisyphus RPM использует флаг <tt>-q</tt> (quiet) по умолчанию. Для включения отладочного вывода используйте флаг <tt>-v</tt>.
  
== <tt>%install</tt> ==
+
Для тарболов с отличающимся от рекомендуемого GNU именованием содержимого (когда архив на верхнем уровне содержит лишь соответствующий каталог <tt>имя-версия</tt>), можно применять [https://bugzilla.altlinux.org/show_bug.cgi?id=31778#c7 следующий вариант]:
  
=== <tt>%make_install</tt> ===
+
%setup -c
 +
%setup -DTn %name-%version/%name
 +
 
 +
== %build ==
 +
=== %configure ===
 +
Макрос используется для упрощения выполнения {{path|./configure}} с соответствующими параметрами данной платформы.
 +
Почти всегда вполне достаточно выполнить <tt>%configure</tt> без параметров.
 +
От имени пользователя данный макрос работать не будет.
 +
  %build
 +
  %configure
 +
  %make_build
 +
 
 +
При сборке пакетов проверяйте, нет ли в спеке <tt>--enable-strip</tt>.  Обычно от него нет никакого эффекта, кроме убивания debuginfo на корню<ref>http://lists.altlinux.org/pipermail/devel/2011-March/189039.html</ref>.
 +
 
 +
Если скрипта {{path|configure}} в архиве исходных текстов нет (обычное явление для исходников из git или иных SCM), но есть {{path|configure.ac}} -- следует добавить перед вызовом <tt>%configure</tt> макрос <tt>%autoreconf</tt>.  В иных случаях стоит повнимательней ознакомиться с инструкциями по сборке, раз это не было сделано до сих пор.
 +
 
 +
=== %make_build ===
 +
По умолчанию поддерживает при сборке использование нескольких процессоров/ядер.
 +
 
 +
== %install ==
 +
 
 +
=== %makeinstall_std ===
 +
 
 +
Рекомендуемый вариант, эквивалентный
 +
%make_install DESTDIR=%buildroot install
 +
 
 +
=== %make_install ===
  
 
Этот макрос используется для упрощения установки софта, Makefile которого умеет использовать параметр <tt>DESTDIR</tt> (в частности, весь софт, использующий automake, это умеет):
 
Этот макрос используется для упрощения установки софта, Makefile которого умеет использовать параметр <tt>DESTDIR</tt> (в частности, весь софт, использующий automake, это умеет):
Строка 163: Строка 319:
 
  %make_install DESTDIR=%buildroot %_make_install_target
 
  %make_install DESTDIR=%buildroot %_make_install_target
  
=== <tt>%makeinstall</tt> ===
+
=== %makeinstall ===
  
 
Редко используемый макрос, предназначенный для софта, DESTDIR не умеющего, и <tt>prefix</tt> внутри себя не запоминающего:
 
Редко используемый макрос, предназначенный для софта, DESTDIR не умеющего, и <tt>prefix</tt> внутри себя не запоминающего:
Строка 169: Строка 325:
 
В случае, когда Makefile нужно передать какой-то дополнительный параметр (например, особо странный <tt>somefancydir=%buildroot/fancy/dir</tt>), это выглядит так:
 
В случае, когда Makefile нужно передать какой-то дополнительный параметр (например, особо странный <tt>somefancydir=%buildroot/fancy/dir</tt>), это выглядит так:
 
  %makeinstall somefancydir=%buildroot/fancy/dir
 
  %makeinstall somefancydir=%buildroot/fancy/dir
 +
 +
Иногда требуется запаковать вспомогательные бинарные программы, не предназначеные для выполнения пользователем (обычно их запускают другие программы). Согласно [http://www.gnu.org/prep/standards/html_node/Directory-Variables.html GNU Coding Standards], их следует класть в директорию, определяемую переменной <tt>libexecdir</tt>. В ALT&nbsp;Linux ей соответствует макрос <tt>%_libexecdir</tt>, указывающий на <tt>/usr/lib</tt>. Рекомендуется создавать в этой директории под-папки по названию пакета:
 +
 +
%makeinstall libexecdir=%buildroot%_libexecdir/fancy
 +
 +
Задать путь можно также на этапе конфигурирования:
 +
 +
%build
 +
%configure --libexecdir=%_libexecdir/fancy
  
 
=== Удаление buildroot ===
 
=== Удаление buildroot ===
Строка 174: Строка 339:
 
В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется.
 
В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется.
  
== <tt>%clean</tt> ==
+
== %check ==
 +
 
 +
Начиная с <tt>rpm-4.0.4-alt98.18</tt>, для упрощения проведения автоматических тестов собранного кода поддерживается секция <tt>%check</tt>; типичные примеры её содержания:
 +
 +
* если важно получить ответ на вопрос "не испортилось ли" поскорее, то
 +
  %make_build check
 +
 
 +
* если SMP-сборка не поддерживается, то
 +
  make check
  
Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса <tt>%clean_buildroot</tt>). Таким образом, ручная очистка BuildRoot является ненужной (а точнее - вредной, поскольку повышает вероятность ошибки).
+
* если важно узнать, какие именно тесты не прошли, то следует использовать ключ -k.
 +
 
 +
[http://lists.altlinux.org/pipermail/devel/2009-September/174904.html Обратите внимание:] <tt>%check</tt> выполняется после <tt>%install</tt>, т.е. by design не влияет на результат работы <tt>%install</tt>.
 +
 
 +
Ненулевой код возврата по умолчанию приводит к останову сборки (в т.ч. и на <tt>git.alt</tt>); это возможно изменить при помощи ключей <tt>--disable check</tt>/<tt>--without check</tt>/<tt>--disable test</tt>/<tt>--without test</tt> или макроса
 +
 
 +
%def_disable check
 +
 
 +
Кроме того, отключение <tt>%check</tt> происходит при выполнении под управлением buildreq.
 +
 
 +
При необходимости вытащить для изучения и/или апстрима, например, {{path|testsuite.log}} применяется<ref>[http://lists.altlinux.org/pipermail/devel/2012-May/194279.html vsu@ в devel@]</ref>:
 +
<pre>make check || {
 +
        find -type f -name testsuite.log -print0 | xargs -r0 cat
 +
        exit 1
 +
}</pre>
 +
 
 +
=== BuildRequires только для %check ===
 +
 
 +
Для возможности сборки с облегчёнными сборочными зависимостями (например, при bootstrap-е на новой платформе) желательно оформить BuildRequires только для %check как условные. Как следует из описания механизма выше, годится, например, такое выражение:
 +
 
 +
%{?!_without_test:%{?!_disable_test:%{?!_without_check:%{?!_disable_check:BuildRequires: fakechroot}}}}
 +
 
 +
но на практике[https://packages.altlinux.org/en/Sisyphus/srpms/rpm/spec][https://packages.altlinux.org/en/Sisyphus/srpms/gcc7/spec] часто встречается более короткое выражение:
 +
 
 +
%{?!_without_check:%{?!_disable_check:BuildRequires: fakechroot}}
 +
 
 +
(На свой страх можете ещё сократить это условие.)
 +
 
 +
== %clean ==
 +
 
 +
Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса <tt>%clean_buildroot</tt>). Таким образом, ручная очистка BuildRoot является ненужной (а точнее — вредной, поскольку повышает вероятность ошибки).
  
 
Если секция <tt>%clean</tt> пуста, то рекомендуется вообще не включать её в spec-файл.
 
Если секция <tt>%clean</tt> пуста, то рекомендуется вообще не включать её в spec-файл.
  
== <tt>%files</tt> ==
+
== %files ==
  
 
В отличие от других веток RPM, Sisyphus RPM автоматически подставляет в начало каждой секции <tt>%files</tt> и в начало каждого файла, включаемого с помощью <tt>%files -f</tt>, директиву <tt>%defattr</tt> со значением макроса <tt>%_defattr</tt>.
 
В отличие от других веток RPM, Sisyphus RPM автоматически подставляет в начало каждой секции <tt>%files</tt> и в начало каждого файла, включаемого с помощью <tt>%files -f</tt>, директиву <tt>%defattr</tt> со значением макроса <tt>%_defattr</tt>.
Строка 186: Строка 389:
 
Таким образом, ручное указание <tt>%defattr</tt> является излишним.
 
Таким образом, ручное указание <tt>%defattr</tt> является излишним.
  
== <tt>%changelog</tt> ==
+
== %changelog ==
  
 
{{Main|Руководство по написанию changelog}}
 
{{Main|Руководство по написанию changelog}}
 +
 +
== Примеры ==
 +
 +
{{Main|Spec/sample}}
 +
 +
== Ссылки ==
 +
* [http://docs.altlinux.org/archive/2.2/master/devel-html/ch01s02.html ALT specfile conventions]
 +
* [[Spec/Предопределенные макросы]]
 +
* [[Особенности написания спек файлов в ALT Linux]]
 +
 +
== Примечания ==
 +
<references />

Текущая версия на 14:05, 19 сентября 2020


Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


Работа с upstream-исходниками[править]

Если имя пакета, имя архива с upstream-исходным кодом и имя директории, содержащейся в архиве, не совпадают, не следует перепаковывать архив, чтобы угодить действиям по умолчанию в RPM. Вместо этого стоит указать все названия в spec-файле явно:

%define origname imms

Name: xmms-%origname
#...

Url: http://www.luminal.org/phpwiki/index.php/IMMS
Source: http://www.luminal.org/files/%origname/%origname-%version.tar.bz2

# if we had a published package with original name
Obsoletes: %origname

%prep
%setup -n %origname-%version

Разумеется, это всё относится только к пакетам, собираемым не с помощью Gear.

Включение/выключение подпакетов[править]

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

# По умолчанию будет выключено.
# Одноразово в командной строке rpm/rpmbuild включается с помощью --enable=static
%def_disable static
[...]
# Если заодно необходимо передавать опцию --(disable|enable)-static в configure,
# то можно написать следующую конструкцию.
# (В разных случаях она будет раскрываться в разные значения.)
%configure %{subst_enable static}
[...]
%if_enabled static
%files devel-static
[...]
%endif

Проверка плагинов[править]

У нас в rpm-build >= 4.0.4-alt100.91 есть механизм проверки плагинов, который используется в разных пакетах. Вот, например, ldv когда-то применил его для irssi, выглядит это так (%_bindir/irssi можно прелоадить, потому что он PIE):

export RPM_LD_PRELOAD_irssi=%buildroot%_bindir/irssi
export RPM_FILES_TO_LD_PRELOAD_irssi='%irssi_modules_dir/lib*.so %perl_vendor_autolib/Irssi/*.so'
export RPM_LD_PRELOAD_libperl_core='%buildroot%irssi_modules_dir/libperl_core.so'
export RPM_FILES_TO_LD_PRELOAD_libperl_core='%irssi_modules_dir/libfe_perl.so %perl_vendor_autolib/Irssi/*.so'
%set_verify_elf_method strict

Version[править]

Версия upstream-кода.

В случае упаковки промежуточной версии (1.0-rc1, 1.0-20080105) версия среза упаковывается в поле Release: 1.0rc лексикографически круче 1.0, вследствие чего для нормального обновления 1.0rc до 1.0 придётся

  • добавлять Serial: 1,
  • оформлять как 1.0rel или
  • ждать поднятия версии апстримом.

Чтобы избежать таких сложностей в случае, когда разработчик апстрима именует промежуточные версии без учёта лексикографического порядка сортировки, в номер версии в нужном месте добавляем свой суффикс «.0». Например, в случае планов апстрима после 1.0 выпустить 1.0.1, для промежуточной у апстрима версии 1.0.1-rc1 в спеке пишем 1.0.0.1-rc1.

Расшифровка именования промежуточных версий[править]

На примере libxml2 2.9.4.0.12.e905-alt1:

  • у апстрима v2.9.4-12-ge905f08 — это вывод git describe e905f08;
  • «12» - это количество коммитов, отделяющих коммит «e905f08» от «v2.9.4»;
  • «.0» - это суффикс, добавленный к версии 2.9.4, чтобы получившийся результат 2.9.4.0 был гарантированно меньше любой версии, выпущенной после 2.9.4;
  • «e905» получен с помощью git describe --abbrev=1 e905f08;
  • «2.9.4.0.12.e905» написан по мотивам вывода утилиты git-version-gen из gnulib.

Release[править]

Для пакетов Sisyphus поле Release должно иметь вид в простых случаях — altN, а в сложных (см. ниже) — altN[суффикс].

Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки:

  • 1.0-alt1
  • 1.0-alt2
  • 1.0-alt3
  • 1.1-alt1
  • 1.2-alt1
  • 1.2-alt2

Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов.

Промежуточные upstream-релизы[править]

При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release:

  • 1.0-alt1.r6543
  • 1.0-alt1.20080101
  • 1.0-alt1.rc1
  • 1.0-alt1.rc2
  • 1.0-alt1.gitda39a3ee[1]

Если система контроля версий не предоставляет линейной нумерации коммитов, то с каждым новым срезом нужно увеличивать номер релиза:

  • 1.0-alt1.hg.da39a3ee
  • 1.0-alt2.hg.0d3255bf
  • 1.0-alt3.hg.fef95601

При первой сборке финального upstream-релиза следует поднять номер релиза пакета:

  • 1.0-alt1.gitda39a3ee
  • 1.0-alt2.gitd06f1866
  • 1.0-alt3

Использовать релиз alt0 запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами (в отличие от, например, alt0.1, который при бэкпорте для p7 становится alt0.0.M70P.1).

Бэкпорты[править]


Epoch[править]

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

Будьте осторожны — в имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM-ов с одинаковыми Version и Release и разными Epoch.

Устаревшим синонимом поля Epoch является Serial.

Summary[править]

Cодержит краткое описание пакета. Оно выводится, например, при поиске пакета через apt-cache search. Значение тэга Summary должно начинаться с заглавной буквы. В конце Summary не должно быть точки.

License[править]

  • Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять «or any later version», а также менять указанные версии или смешивать GPL и LGPL).
  • Несвободные лицензии должны быть указаны как «distributable»

При указании лицензии рекомендуется пользоваться макросами из пакета rpm-build-licenses, добавив его в список BuildRequires.

Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в /usr/share/license (пакет common-licenses). Если же таковой файл там присутствует, то достаточно указать название лицензии в тэге пакета.

Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно.

С ноября 2019 года в sisyphus_check в режиме предупреждения включена проверка на соответствие содержимого тега License: классификации SPDX (соответственно дополнено содержимое пакета common-licenses).

Group[править]

Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле /usr/lib/rpm/GROUPS, находящемся в пакете rpm.

Url[править]

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

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

Для тега Url можно использовать утилиту rpmurl из пакета etersoft-build-utils:

rpmurl -c пакет.spec

Source[править]

Если сборка производится без использования gear, то в Source настоятельно рекомендуется указывать действующий URL архива исходного кода относительно тэга Url:

Source: %url/some/thing/%name-%version.tar.bz2

Формат Source для известных хостингов:

# иногда проект называется не так, как пакет, будьте внимательны
Source: http://dl.sourceforge.net/%name/%name-%version.tar.bz2
Source: http://download.berlios.de/%name/%name-%version.tar.bz2

Если тарбол формируется из gear-репозитория, то в Source указывается имя файла согласно прописанному в .gear/rules, например

Source: %name-%version.tar

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

# svn co svn://svnanon.samba.org/samba/trunk samba-trunk -r 1
Source: %name.tar.bz2

Patch[править]

Рекомендуемое именование патчей:

  • NAME-VERSION-ORIGIN-WHAT.patch, где
    • NAME и VERSION — имя и версия пакета, для которого сделан патч,
    • ORIGIN — аббревиатура источников патча (обычно дистрибутивов),
    • WHAT — краткое описание патча.

Если патч образован из нескольких частей, полученных из разных источников, ORIGIN должен включать аббревиатуры всех источников. Аббревиатура ALT Linux / Sisyphus — alt. Для патчей, полученных на основе системы контроля версий, ORIGIN должен включать в себя дату или номер ревизии.

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

  • makefile — патчи, затрагивающие исключительно Makefile*,
  • bound — проверки на границы (буфера, целых чисел и т. д.),
  • config — патчи, затрагивающие исключительно конфигурационные файлы,
  • configure — патчи, затрагивающие исключительно configure*,
  • doc — патчи, затрагивающие исключительно документацию,
  • fixes — кумулятивные патчи/исправления по надёжности и/или безопасности,
  • format — патчи на использование форматирования строк (типа printf),
  • install — патчи на выполнение make install непривилегированным пользователем,
  • linux — патчи для портирования По на Linux,
  • man — патчи, затрагивающие исключительно man-страницы,
  • texinfo — патчи, затрагивающие исключительно документацию в формате texinfo,
  • tmp — патчи, предназначенные для решения различных вопросов, связанных с временными файлами,
  • vitmp — патчи для поддержки vitmp(1)
  • warnings — патчи, исправляющие предупреждения, выданные компилятором

(начиная с rpm-build 4.0.4-alt133) Все патчи, описанные в основной секции spec-файла, можно в секции %prep применить директивой %autopatch. %autopatch принимает опции -p и -F, аналогичные таким же опциям директивы %patch.

Requires, PreReq[править]

При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так:

Requires: %name = %epoch:%version-%release

Requires[править]

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

Requires:  java >= 1.6

BuildRequires, BuildPreReq, BuildRequires(pre)[править]

Тэг BuildRequires используется для хранения результатов работы buildreq. По этой причине дополнительные сборочные зависимости, не находящиеся buildreq, рекомендуется хранить в тэге BuildPreReq.

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

  • запуском buildreq со всеми включенными опциями,
  • указанием дополнительных зависимостей в BuildPreReq и периодическим их обновлением.

При необходимости наличия в окружении, где выполняется раскрытие макросов для создания src.rpm, дополнительных пакетов rpm-macros-* либо rpm-build-* их следует указать тэгом BuildRequires(pre). Злоупотреблять им не следует (затрудняет бутстрапы); критерий необходимости именно этой формы -- ошибка (не предупреждение!) при попытке выполнить в недостаточном окружении команду вида

rpm -bs --nodeps этот.spec

Обратите внимание, что для gear-rpm ограничения иные и этот критерий неприменим.

BuildArch[править]

Используется для указания архитектуры (под)пакета. Возможные значения:

  • x86_64
  • %ix86[2] или индивидуально i386, i586, i686...
  • noarch

В случае указания среди тегов основного пакета определяет архитектуру всех подпакетов; для индивидуальных подпакетов — как правило, с данными, документацией либо скриптами — допускается указание только noarch, и то при условии использования rpm-4.0.4-alt94 или более новой сборки.

BuildRoot[править]

Тэг BuildRoot бесполезен для RPM из Sisyphus: обработку BuildRoot RPM производит самостоятельно.

BuildHost[править]

Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова uname(2).

Prefix[править]

Тэг Prefix в Sisyphus RPM не нужен, он самостоятельно устанавливается в /usr.

Conflicts[править]

Применяется для указания наличия конфликта (обязательно в случае файлового/RPC и желательно в случае существенного смыслового) между данным пакетом и указываемым. Не надо ставить конфликты на то, чего ещё нет и о чём, соответственно, ничего не известно. Достаточно проставить односторонне.

Provides[править]

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

Provides: something = %version-%release

При переименовании пакета обязательно сочетается с Obsoletes:.

Obsoletes[править]

Перечисляет пакеты/версии, объявленные устаревшими. Обычно применяется при переименовании пакета в сочетании с Provides: и с указанием версии, меньшей или равной последней известной версии пакета под старым названием:

Name: someproject
Version: 1.0
Release: alt1
# ...
Provides: oldproject = %version-%release
Obsoletes: oldproject <= 0.9.1

(Примечание: Реагирует ли сборочница на переименование пакетов.)

%description[править]

Здесь указывается описание пакета. Данное описание учитывается при поиске пакета через apt-cache search и полностью выводится во время просмотра информации о пакете при помощи apt-cache show имя_пакета.

Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику:

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

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

%prep[править]

%setup[править]

Макрос %setup распаковывает исходный код перед компиляцией.

Конструкция %setup в Sisyphus RPM использует флаг -q (quiet) по умолчанию. Для включения отладочного вывода используйте флаг -v.

Для тарболов с отличающимся от рекомендуемого GNU именованием содержимого (когда архив на верхнем уровне содержит лишь соответствующий каталог имя-версия), можно применять следующий вариант:

%setup -c
%setup -DTn %name-%version/%name

%build[править]

%configure[править]

Макрос используется для упрощения выполнения ./configure с соответствующими параметрами данной платформы. Почти всегда вполне достаточно выполнить %configure без параметров. От имени пользователя данный макрос работать не будет.

 %build
 %configure
 %make_build

При сборке пакетов проверяйте, нет ли в спеке --enable-strip. Обычно от него нет никакого эффекта, кроме убивания debuginfo на корню[3].

Если скрипта configure в архиве исходных текстов нет (обычное явление для исходников из git или иных SCM), но есть configure.ac -- следует добавить перед вызовом %configure макрос %autoreconf. В иных случаях стоит повнимательней ознакомиться с инструкциями по сборке, раз это не было сделано до сих пор.

%make_build[править]

По умолчанию поддерживает при сборке использование нескольких процессоров/ядер.

%install[править]

%makeinstall_std[править]

Рекомендуемый вариант, эквивалентный

%make_install DESTDIR=%buildroot install

%make_install[править]

Этот макрос используется для упрощения установки софта, Makefile которого умеет использовать параметр DESTDIR (в частности, весь софт, использующий automake, это умеет):

%make_install DESTDIR=%buildroot install

или

%make_install DESTDIR=%buildroot %_make_install_target

%makeinstall[править]

Редко используемый макрос, предназначенный для софта, DESTDIR не умеющего, и prefix внутри себя не запоминающего:

%makeinstall

В случае, когда Makefile нужно передать какой-то дополнительный параметр (например, особо странный somefancydir=%buildroot/fancy/dir), это выглядит так:

%makeinstall somefancydir=%buildroot/fancy/dir

Иногда требуется запаковать вспомогательные бинарные программы, не предназначеные для выполнения пользователем (обычно их запускают другие программы). Согласно GNU Coding Standards, их следует класть в директорию, определяемую переменной libexecdir. В ALT Linux ей соответствует макрос %_libexecdir, указывающий на /usr/lib. Рекомендуется создавать в этой директории под-папки по названию пакета:

%makeinstall libexecdir=%buildroot%_libexecdir/fancy

Задать путь можно также на этапе конфигурирования:

%build
%configure --libexecdir=%_libexecdir/fancy

Удаление buildroot[править]

В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется.

%check[править]

Начиная с rpm-4.0.4-alt98.18, для упрощения проведения автоматических тестов собранного кода поддерживается секция %check; типичные примеры её содержания:

  • если важно получить ответ на вопрос "не испортилось ли" поскорее, то
 %make_build check
  • если SMP-сборка не поддерживается, то
 make check
  • если важно узнать, какие именно тесты не прошли, то следует использовать ключ -k.

Обратите внимание: %check выполняется после %install, т.е. by design не влияет на результат работы %install.

Ненулевой код возврата по умолчанию приводит к останову сборки (в т.ч. и на git.alt); это возможно изменить при помощи ключей --disable check/--without check/--disable test/--without test или макроса

%def_disable check

Кроме того, отключение %check происходит при выполнении под управлением buildreq.

При необходимости вытащить для изучения и/или апстрима, например, testsuite.log применяется[4]:

make check || {
        find -type f -name testsuite.log -print0 | xargs -r0 cat
        exit 1
}

BuildRequires только для %check[править]

Для возможности сборки с облегчёнными сборочными зависимостями (например, при bootstrap-е на новой платформе) желательно оформить BuildRequires только для %check как условные. Как следует из описания механизма выше, годится, например, такое выражение:

%{?!_without_test:%{?!_disable_test:%{?!_without_check:%{?!_disable_check:BuildRequires: fakechroot}}}}

но на практике[1][2] часто встречается более короткое выражение:

%{?!_without_check:%{?!_disable_check:BuildRequires: fakechroot}}

(На свой страх можете ещё сократить это условие.)

%clean[править]

Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса %clean_buildroot). Таким образом, ручная очистка BuildRoot является ненужной (а точнее — вредной, поскольку повышает вероятность ошибки).

Если секция %clean пуста, то рекомендуется вообще не включать её в spec-файл.

%files[править]

В отличие от других веток RPM, Sisyphus RPM автоматически подставляет в начало каждой секции %files и в начало каждого файла, включаемого с помощью %files -f, директиву %defattr со значением макроса %_defattr.

Таким образом, ручное указание %defattr является излишним.

%changelog[править]


Примеры[править]

Основная статья: Spec/sample


Ссылки[править]

Примечания[править]

  1. для ссылки на коммит удобен git describe
  2. См. rpm --eval %ix86
  3. http://lists.altlinux.org/pipermail/devel/2011-March/189039.html
  4. vsu@ в devel@