SpecfileConventions

При разработке этих правил решались следующие задачи:

• Обеспечить желаемую функциональность. Пакеты должны отвечать правилам упаковки, о которых речь идёт в SecurePackagingPolicy. Для этого надо, чтобы spec-файлы обеспечивали выполнение этих правил.
• Помочь разработчику. Так как spec-файлы все ещё пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками.

spec-файлы

Устаревшие конструкции

Не следует использовать устаревшие конструкции — они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям относятся:

• тэг BuildRoot (BuildRoot выбирается автоматически);
• строки вида rm -rf $RPM_BUILD_ROOT (BuildRoot очищается автоматически);
• %_defattr со стандартными аргументами в начале файлов и секций %files (такое поведение действует по умолчанию);
• секция %clean, пустая либо без разумного содержания.

Фигурные скобки

Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавиться от них можно с помощью команды cleanup_spec из пакета rpm-utils.

Выравнивание

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

Порядок тэгов

Рекомендуемый порядок заголовочных тэгов:

• Name
• Version
• Release
• Epoch (Serial)

• Summary
• License
• Group
• Url
• Packager
• BuildArch

• Source*
• Patch*

• PreReqs
• Requires
• Provides
• Conflicts

• Prefix
• BuildPreReqs
• BuildRequires.

Разумеется, не все из вышеперечисленных тэгов используются во всех пакетах, равно как встречаются и другие редко используемые тэги.

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

Значения тэгов

Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы. Значение тэга Summary не следует завершать точкой. Значения тэга Summary и секции %description могут содержать названия команд только в не изменённом виде.

Группы

Значение тэга Group должно соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле /usr/lib/rpm/GROUPS.

ChangeLog

Для формирования первой строки changelog-записи удобно использовать утилиту add_changelog из пакета rpm-utils.

Файлы локализации

Если в состав пакета входят файлы локализации либо другие файлы на разных языках, следует использовать макрос %find_lang. Подробную информацию можно получить, выполнив команду /usr/lib/rpm/find-lang -h.

Внутрипакетные зависимости

При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также версию, релиз и epoch (если есть). Например, Requires: %name = %version-%release или Requires: %name = %epoch:%version-%release. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружён пробелами.

Разделяемые библиотеки

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

По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса lib либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.

Статические библиотеки

Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: в списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.

Переименование пакетов

Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:

Provides: старое_имя = %version
Obsoletes: старое_имя

Патчи

Наименование патчей

При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: NAME-VERSION-ORIGIN-WHAT.patch, где

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

В случае, когда патч образован из нескольких частей, полученных из разных источников, компонента имени ORIGIN должна содержать аббревиатуры всех источников. Если патч был создан или адаптирован для ALT Linux, то в ORIGIN, соответственно, должно присутствовать -alt-. Для патчей, созданных на базе CVS, компонента имени ORIGIN должна начинаться с cvs-YYYYMMDD.

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

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