Spec

В данном документе концентрируются отличия Sisyphus RPM от остальных веток RPM, влияющие на содержание spec-файлов.

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

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

• 1.0-alt2

Использовать релиз 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.

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).

%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

%clean

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

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

%files

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

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