Spec: различия между версиями
Строка 1: | Строка 1: | ||
{{Stub}} | {{Stub}} | ||
== | == <tt>Release</tt> == | ||
=== <tt>Summary</tt> | Для пакетов Sisyphus поле <tt>Release</tt> должно иметь вид в простых случах - <tt>altN</tt>, а в сложных (см. ниже) - <tt>altN[суффикс]</tt>. | ||
Релиз пакета используется для указания номера сборки пакета при данной версии 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-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле <tt>Release</tt>: | |||
* 1.0-alt1.r6543 | |||
* 1.0-alt1.20080101 | |||
* 1.0-alt1.rc1 | |||
* 1.0-alt1.rc2 | |||
При первой сборке финального upstream-релиза следует поднять номер релиза пакета: | |||
* 1.0-alt2 | |||
=== Бэкпорты === | |||
{{Main|BackportsPolicy#Правила нумерации релизов}} | |||
== <tt>Summary</tt> == | |||
Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки. | Значение тэга <tt>Summary</tt> должно начинаться с заглавной буквы. В конце <tt>Summary</tt> не должно быть точки. | ||
== <tt>License</tt> == | |||
* Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL). | * Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете (в частности, не разрешается отбрасывать или добавлять "or any later version", а также менять указанные версии или смешивать GPL и LGPL). | ||
Строка 17: | Строка 46: | ||
Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно. | Лицензию с добавками к стандартному тексту (например, GPLv2 с дополнительной секцией в ядре Linux) упаковывать обязательно. | ||
== <tt>Group</tt> == | |||
Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>. | Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле <tt>/usr/lib/rpm/GROUPS</tt>, находящемся в пакете <tt>rpm</tt>. | ||
== <tt>Patch</tt> == | |||
Рекомендуемое именование патчей: | Рекомендуемое именование патчей: | ||
Строка 47: | Строка 76: | ||
* <tt>warnings</tt> — патчи, исправляющие предупреждения, выданные компилятором | * <tt>warnings</tt> — патчи, исправляющие предупреждения, выданные компилятором | ||
== <tt>Requires</tt>, <tt>PreReq</tt> == | |||
При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так: | При наличии логических зависимостей между пакетами внутри одного spec-файла, пакетная зависимость между ними должна включать полную версию пакета, например так: | ||
Requires: %name = %epoch:%version-%release | Requires: %name = %epoch:%version-%release | ||
== <tt>BuildRequires</tt>, <tt>BuildPreReq</tt> == | |||
Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>. | Тэг <tt>BuildRequires</tt> используется для хранения результатов работы [[buildreq]]. По этой причине дополнительные сборочные зависимости, не находящиеся <tt>buildreq</tt>, рекомендуется хранить в тэге <tt>BuildPreReq</tt>. | ||
== <tt>BuildRoot</tt> == | |||
Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно. | Тэг <tt>BuildRoot</tt> бесполезен для RPM из Sisyphus: обработку <tt>BuildRoot</tt> RPM производит самостоятельно. | ||
== <tt>BuildHost</tt> == | |||
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>. | Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова <tt>uname(2)</tt>. |
Версия от 00:41, 4 ноября 2008
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
При первой сборке финального upstream-релиза следует поднять номер релиза пакета:
- 1.0-alt2
Бэкпорты
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.
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.
BuildRoot
Тэг BuildRoot бесполезен для RPM из Sisyphus: обработку BuildRoot RPM производит самостоятельно.
BuildHost
Новый опциональный тэг в Sisyphus RPM. Позволяет переопределить имя сборочного хоста. По умолчанию используется, как и в остальных версиях RPM, результат вызова uname(2).
%package
%description
Описание пакета должно содержать информацию, интересную его пользователю, а не сборщику:
- Описание программы или инструмента должно содержать их функционал, а не особенности реализации (язык, используемые библиотеки и т.д.)
- Описание библиотеки должно содержать язык программирования, для которого предназначена библиотека и решаемую задачу
- ...
%prep
%build
%install
%clean
Sisyphus RPM автоматически очищает BuildRoot пакета (с помощью макроса %clean_buildroot). Таким образом, ручная очистка BuildRoot является ненужной (а точнее - вредной, поскольку повышает вероятность ошибки).
Если секция %clean пуста, то рекомендуется вообще не включать её в spec-файл.
%pre
%post
%preun
%postun
%triggerpostun
%files
В отличие от других веток RPM, Sisyphus RPM автоматически подставляет в начало каждой секции %files и в начало каждого файла, включаемого с помощью %files -f, директиву %defattr со значением макроса %_defattr.
Таким образом, ручное указание %defattr является излишним.