SpecfileConventions

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
м (Добавлена категория RPM spec)
(Merged to ALT_Packaging_HOWTO)
 
(2 промежуточные версии не показаны)
Строка 1: Строка 1:
-
При разработке этих правил решались следующие задачи:
+
#REDIRECT [[ALT_Packaging_HOWTO]]
-
 
+
-
* Обеспечить желаемую функциональность. Пакеты должны отвечать правилам упаковки, о которых речь идёт в [[SecurePackagingPolicy]]. Для этого надо, чтобы spec-файлы обеспечивали выполнение этих правил.
+
-
* Помочь разработчику. Так как spec-файлы ''все ещё'' пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками.
+
-
 
+
-
== spec-файлы ==
+
-
 
+
-
=== Устаревшие конструкции ===
+
-
 
+
-
Не следует использовать устаревшие конструкции  — они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям относятся:
+
-
* тэг <tt>BuildRoot</tt> (BuildRoot выбирается автоматически);
+
-
* строки вида <tt>rm -rf $RPM_BUILD_ROOT</tt> (BuildRoot очищается автоматически);
+
-
* <tt>%_defattr</tt> со стандартными аргументами в начале файлов и секций <tt>%files</tt> (такое поведение действует по умолчанию);
+
-
* секция <tt>%clean</tt>, пустая либо без разумного содержания.
+
-
 
+
-
=== Фигурные скобки ===
+
-
 
+
-
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавиться от них можно с помощью команды <tt>cleanup_spec</tt> из пакета <tt>rpm-utils</tt>.
+
-
 
+
-
=== Выравнивание ===
+
-
 
+
-
Используйте табуляции для выравнивания. Избегайте пробельных символов в конце строк.
+
-
 
+
-
=== Порядок тэгов ===
+
-
 
+
-
Рекомендуемый порядок заголовочных тэгов:
+
-
* Name
+
-
* Version
+
-
* Release
+
-
* Epoch (Serial)
+
-
 
+
-
* Summary
+
-
* License
+
-
* Group
+
-
* Url
+
-
* Packager
+
-
* BuildArch
+
-
 
+
-
* Source*
+
-
* Patch*
+
-
 
+
-
* PreReqs
+
-
* Requires
+
-
* Provides
+
-
* Conflicts
+
-
 
+
-
* Prefix
+
-
* BuildPreReqs
+
-
* BuildRequires.
+
-
 
+
-
Разумеется, не все из вышеперечисленных тэгов используются во всех пакетах, равно как встречаются и другие редко используемые тэги.
+
-
 
+
-
В связи с тем, что BuildRequires зарезервирован для автоматически вычисляемых зависимостей, для указания особых зависимостей следует использовать BuildPreReq.
+
-
 
+
-
=== Значения тэгов ===
+
-
 
+
-
Значение тэга от его имени следует разделять одним пробелом. Элементы списка значений следует разделять запятой с последующим пробелом. Значение тэга Summary следует начинать с прописной буквы. Значение тэга <tt>Summary</tt> не следует завершать точкой. Значения тэга <tt>Summary</tt> и секции <tt>%description</tt> могут содержать названия команд только в не изменённом виде.
+
-
 
+
-
=== Группы ===
+
-
 
+
-
Значение тэга <tt>Group</tt> должно соответствовать действительности и при этом принадлежать фиксированному множеству, перечисленному в файле <tt>/usr/lib/rpm/GROUPS</tt>.
+
-
 
+
-
=== ChangeLog ===
+
-
{{Main|Руководство по написанию changelog}}
+
-
Для формирования первой строки changelog-записи удобно использовать утилиту <tt>add_changelog</tt> из пакета <tt>rpm-utils</tt>.
+
-
 
+
-
=== Файлы локализации ===
+
-
 
+
-
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, следует использовать макрос <tt>%find_lang</tt>. Подробную информацию можно получить, выполнив команду <tt>/usr/lib/rpm/find-lang -h</tt>.
+
-
 
+
-
=== Внутрипакетные зависимости ===
+
-
 
+
-
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также версию, релиз и epoch (если есть). Например, <tt>Requires: %name = %version-%release</tt> или <tt>Requires: %name = %epoch:%version-%release</tt>. Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружён пробелами.
+
-
 
+
-
=== Разделяемые библиотеки ===
+
-
 
+
-
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это, в частности, позволяет уменьшить количество циклических зависимостей.
+
-
 
+
-
По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса lib либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
+
-
 
+
-
=== Статические библиотеки ===
+
-
 
+
-
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя devel-подпакета заканчивается суффиксом -devel, то имя нового devel-static-подпакета будет заканчиваться суффиксом -devel-static. При разделении подпакетов следует помнить о внутрипакетных зависимостях: в списке зависимостей devel-static-подпакета должна присутствовать зависимость от -devel = %version-%release.
+
-
 
+
-
=== Переименование пакетов ===
+
-
 
+
-
Иногда пакеты переименовывают. Например, это случается при упаковке разделяемых библиотек. В таких случаях следует указывать правильную информацию о зависимостях, необходимую для корректного обновления. В частности, должен присутствовать:
+
-
 
+
-
<pre>
+
-
Provides: старое_имя = %version
+
-
Obsoletes: старое_имя
+
-
</pre>
+
-
 
+
-
== Патчи ==
+
-
 
+
-
=== Наименование патчей ===
+
-
 
+
-
При создании новых патчей, а также при импортировании патчей из других источников необходимо придерживаться единых правил наименования имён патч-файлов: 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 - патчи, исправляющие ошибки, найденные компилятором.
+
-
 
+
-
[[Category:Sisyphus]]
+
-
[[Category:Devel]]
+
-
[[Category:Руководства]]
+
-
[[Category:RPM spec]]
+

Текущая версия на 10:00, 13 февраля 2011

  1. REDIRECT ALT_Packaging_HOWTO
 
Личные инструменты