Spec: различия между версиями
(→Patch) |
Ilis (обсуждение | вклад) Нет описания правки |
||
Строка 44: | Строка 44: | ||
== Release == | == Release == | ||
Для пакетов Sisyphus поле {{term|Release}} должно иметь вид в простых | Для пакетов Sisyphus поле {{term|Release}} должно иметь вид в простых случах — {{pkg|altN}}, а в сложных (см. ниже) — {{pkg|altN[суффикс]}}. | ||
Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки: | Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода, N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки: | ||
Строка 56: | Строка 56: | ||
* … | * … | ||
Два особых | Два особых случая — это упаковка промежуточных релизов upstream-кода и упаковка бэкпортов. | ||
<div id="intermediate"></div> | <div id="intermediate"></div> | ||
Строка 86: | Строка 86: | ||
* {{pkg|1.0-alt3}} | * {{pkg|1.0-alt3}} | ||
Использовать релиз {{pkg|alt0}} | Использовать релиз {{pkg|alt0}} запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами. | ||
=== Бэкпорты === | === Бэкпорты === | ||
Строка 92: | Строка 92: | ||
{{Main|BackportsPolicy#Правила нумерации релизов}} | {{Main|BackportsPolicy#Правила нумерации релизов}} | ||
== | == Epoch == | ||
Поле Epoch используется тогда, когда по какой-то причине (странное поведение upstream-а, ошибочная заливка пакета или похожие форс-мажорные обстоятельства) требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля <tt>Epoch</tt> увеличивается на единицу по сравнению с предыдущим (отсутствие поля <tt>Epoch</tt> эквивалентно значению 0), версия и релиз устанавливаются в нужное значение. | Поле Epoch используется тогда, когда по какой-то причине (странное поведение upstream-а, ошибочная заливка пакета или похожие форс-мажорные обстоятельства) требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля <tt>Epoch</tt> увеличивается на единицу по сравнению с предыдущим (отсутствие поля <tt>Epoch</tt> эквивалентно значению 0), версия и релиз устанавливаются в нужное значение. | ||
Строка 100: | Строка 100: | ||
Устаревшим синонимом поля <tt>Epoch</tt> является <tt>Serial</tt>. | Устаревшим синонимом поля <tt>Epoch</tt> является <tt>Serial</tt>. | ||
== | == Summary == | ||
Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки. | Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки. | ||
== | == License == | ||
* Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL). | * Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL). | ||
Строка 115: | Строка 115: | ||
Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно. | Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно. | ||
== | == Group == | ||
Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>. | Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>. | ||
== | == Url == | ||
В тэге <tt>Url</tt> настоятельно рекомендуется указывать действующий URL домашней страницы проекта, либо если таковой нет - любого другого места, где можно получить архив с исходным кодом. | В тэге <tt>Url</tt> настоятельно рекомендуется указывать действующий URL домашней страницы проекта, либо если таковой нет - любого другого места, где можно получить архив с исходным кодом. | ||
Строка 148: | Строка 148: | ||
Рекомендуемое именование патчей: | Рекомендуемое именование патчей: | ||
* {{term|NAME-VERSION-ORIGIN-WHAT.patch}}, где | * {{term|NAME-VERSION-ORIGIN-WHAT.patch}}, где | ||
** {{term|NAME}} и {{term|VERSION}} | ** {{term|NAME}} и {{term|VERSION}} — имя и версия пакета, для которого сделан патч, | ||
** {{term|ORIGIN}} | ** {{term|ORIGIN}} — аббревиатура источников патча (обычно дистрибутивов), | ||
** {{term|WHAT}} | ** {{term|WHAT}} — краткое описание патча. | ||
Если патч образован из нескольких частей, полученных из разных источников, {{term|ORIGIN}} должен включать аббревиатуры всех источников. Аббревиатура ALT Linux / | Если патч образован из нескольких частей, полученных из разных источников, {{term|ORIGIN}} должен включать аббревиатуры всех источников. Аббревиатура ALT Linux / Sisyphus — {{term|alt}}. Для патчей, полученных на основе системы контроля версий, {{term|ORIGIN}} должен включать в себя дату или номер ревизии. | ||
В описании патча рекомендуется пользоваться следующими сокращениями: | В описании патча рекомендуется пользоваться следующими сокращениями: | ||
* {{term|makefile}} | * {{term|makefile}} — патчи, затрагивающие исключительно {{path|Makefile*}}, | ||
* {{term|bound}} | * {{term|bound}} — проверки на границы (буфера, целых чисел и т. д.), | ||
* {{term|config}} | * {{term|config}} — патчи, затрагивающие исключительно конфигурационные файлы, | ||
* {{term|configure}} | * {{term|configure}} — патчи, затрагивающие исключительно {{path|configure*}}, | ||
* {{term|doc}} | * {{term|doc}} — патчи, затрагивающие исключительно документацию, | ||
* {{term|fixes}} | * {{term|fixes}} — кумулятивные патчи/исправления по надёжности и/или безопасности, | ||
* {{term|format}} | * {{term|format}} — патчи на использование форматирования строк (типа {{term|printf}}), | ||
* {{term|install}} | * {{term|install}} — патчи на выполнение {{cmd|make install}} непривилегированным пользователем, | ||
* {{term|linux}} | * {{term|linux}} — патчи для портирования По на Linux, | ||
* {{term|man}} | * {{term|man}} — патчи, затрагивающие исключительно man-страницы, | ||
* {{term|texinfo}} | * {{term|texinfo}} — патчи, затрагивающие исключительно документацию в формате {{term|texinfo}}, | ||
* {{term|tmp}} | * {{term|tmp}} — патчи, предназначенные для решения различных вопросов, связанных с временными файлами, | ||
* {{term|vitmp}} | * {{term|vitmp}} — патчи для поддержки {{term|vitmp(1)}} | ||
* {{term|warnings}} | * {{term|warnings}} — патчи, исправляющие предупреждения, выданные компилятором | ||
== | == Requires, PreReq == | ||
При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так: | При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так: | ||
Requires: %name = %epoch:%version-%release | Requires: %name = %epoch:%version-%release | ||
== | == BuildRequires, BuildPreReq == | ||
Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>. | Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>. | ||
Строка 183: | Строка 183: | ||
* указанием дополнительных зависимостей в <tt>BuildPreReq</tt> и периодическим их обновлением. | * указанием дополнительных зависимостей в <tt>BuildPreReq</tt> и периодическим их обновлением. | ||
== | == BuildRoot == | ||
Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно. | Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно. | ||
== | == BuildHost == | ||
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>. | Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>. | ||
== | == Prefix == | ||
Тэг <tt>Prefix</tt> в Sisyphus RPM не нужен, он самостоятельно устанавливается в <tt>/usr</tt>. | Тэг <tt>Prefix</tt> в Sisyphus RPM не нужен, он самостоятельно устанавливается в <tt>/usr</tt>. | ||
== | == %description == | ||
Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику: | Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику: | ||
Строка 202: | Строка 202: | ||
* ... | * ... | ||
== | == %prep == | ||
=== | === %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>. | ||
== | == %install == | ||
=== | === %make_install === | ||
Этот макрос используется для упрощения установки софта, Makefile которого умеет использовать параметр <tt>DESTDIR</tt> (в частности, весь софт, использующий automake, это умеет): | Этот макрос используется для упрощения установки софта, Makefile которого умеет использовать параметр <tt>DESTDIR</tt> (в частности, весь софт, использующий automake, это умеет): | ||
Строка 217: | Строка 217: | ||
%make_install DESTDIR=%buildroot %_make_install_target | %make_install DESTDIR=%buildroot %_make_install_target | ||
=== | === %makeinstall === | ||
Редко используемый макрос, предназначенный для софта, DESTDIR не умеющего, и <tt>prefix</tt> внутри себя не запоминающего: | Редко используемый макрос, предназначенный для софта, DESTDIR не умеющего, и <tt>prefix</tt> внутри себя не запоминающего: | ||
Строка 228: | Строка 228: | ||
В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется. | В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется. | ||
== | == %clean == | ||
Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса <tt>%clean_buildroot</tt>). Таким образом, ручная очистка BuildRoot является ненужной (а точнее - вредной, поскольку повышает вероятность ошибки). | Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса <tt>%clean_buildroot</tt>). Таким образом, ручная очистка BuildRoot является ненужной (а точнее - вредной, поскольку повышает вероятность ошибки). | ||
Строка 234: | Строка 234: | ||
Если секция <tt>%clean</tt> пуста, то рекомендуется вообще не включать её в spec-файл. | Если секция <tt>%clean</tt> пуста, то рекомендуется вообще не включать её в spec-файл. | ||
== | == %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>. | ||
Строка 240: | Строка 240: | ||
Таким образом, ручное указание <tt>%defattr</tt> является излишним. | Таким образом, ручное указание <tt>%defattr</tt> является излишним. | ||
== | == %changelog == | ||
{{Main|Руководство по написанию changelog}} | {{Main|Руководство по написанию changelog}} |
Версия от 14:32, 24 ноября 2008
В данном документе концентрируются отличия Sisyphus RPM от остальных веток RPM, влияющие на содержание spec-файлов.
Работа с 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 новой архитектуры). Это делается следующим образом:
# Включается с помощью --enable=static в командной строке rpm/rpmbuild. %def_disable static [...] # Если необходимо передать опцию --(disable|enable)-static в configure %configure %{subst_enable static} [...] %if_enabled static %files devel-static [...] %endif
Version
Версия upstream-кода. В случае упаковки промежуточной версии (1.0-rc1, 1.0-20080105) версия среза упаковывается в поле Release.
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.0-alt1.hg.da39a3ee
- 1.0-alt2.hg.0d3255bf
- 1.0-alt3.hg.fef95601
Для линеаризации номера версии в git можно использовать git describe:
- 1.0-alt1.git1.5.4-1-g18208b2
- 1.0-alt1.git1.5.4-2-93f1595a
- 1.0-alt1.git1.5.4-3-8be800af
При первой сборке финального upstream-релиза следует поднять номер релиза пакета:
- 1.0-alt1.gitda39a3ee
- 1.0-alt2.gitd06f1866
- 1.0-alt3
Использовать релиз alt0 запрещено — пакет с таким релизом, попав в репозиторий, порождает проблемы с бэкпортами.
Бэкпорты
Epoch
Поле Epoch используется тогда, когда по какой-то причине (странное поведение upstream-а, ошибочная заливка пакета или похожие форс-мажорные обстоятельства) требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля Epoch увеличивается на единицу по сравнению с предыдущим (отсутствие поля Epoch эквивалентно значению 0), версия и релиз устанавливаются в нужное значение.
Будьте осторожны - в имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM-ов с одинаковыми Version и Release и разными Epoch.
Устаревшим синонимом поля Epoch является Serial.
Summary
Значение тэга Summary должно начинаться с заглавной буквы. В конце Summary не должно быть точки.
License
- Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL).
- Несвободные лицензии должны быть указаны как "distributable"
При указании лицензии рекомендуется пользоваться макросами из пакета rpm-build-licenses.
Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в /usr/share/license (пакет common-licenses). Если же таковой файл там присутствует, то достаточно указать название лицензии в тэге пакета.
Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно.
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 — патчи, исправляющие предупреждения, выданные компилятором
Requires, PreReq
При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так:
Requires: %name = %epoch:%version-%release
BuildRequires, BuildPreReq
Тэг BuildRequires используется для хранения результатов работы buildreq. По этой причине дополнительные сборочные зависимости, не находящиеся buildreq, рекомендуется хранить в тэге BuildPreReq.
Если в пакете имеются опциональные части (включаемые с помощью конструкций %if или подобных), то сборочные зависимости должны содержать пакеты, достаточные для сборки всех опциональных частей. Этого можно добиться двумя способами:
- запуском buildreq со всеми включенными опциями,
- указанием дополнительных зависимостей в BuildPreReq и периодическим их обновлением.
BuildRoot
Тэг BuildRoot бесполезен для RPM из Sisyphus: обработку BuildRoot RPM производит самостоятельно.
BuildHost
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова uname(2).
Prefix
Тэг Prefix в Sisyphus RPM не нужен, он самостоятельно устанавливается в /usr.
%description
Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику:
- Описание программы или инструмента должно содержать их функционал, а не особенности реализации (язык, используемые библиотеки и т.д.)
- Описание библиотеки должно содержать язык программирования, для которого предназначена библиотека и решаемую задачу
- ...
%prep
%setup
Конструкция %setup в Sisyphus RPM использует флаг -q (quiet) по умолчанию. Для включения отладочного вывода используйте флаг -v.
%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
Удаление buildroot
В Sisyphus RPM buildroot удаляется самим RPM, и поэтому удалять его вручную не требуется.
%clean
Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса %clean_buildroot). Таким образом, ручная очистка BuildRoot является ненужной (а точнее - вредной, поскольку повышает вероятность ошибки).
Если секция %clean пуста, то рекомендуется вообще не включать её в spec-файл.
%files
В отличие от других веток RPM, Sisyphus RPM автоматически подставляет в начало каждой секции %files и в начало каждого файла, включаемого с помощью %files -f, директиву %defattr со значением макроса %_defattr.
Таким образом, ручное указание %defattr является излишним.