По этой причине мы рекомендуем сборщикам пакетов использовать следующий шаблон spec-файла, это упростит жизнь остальным, если кто-то подберёт ваш пакет или захочет внести в него изменения. Если каждый будет следовать одному и тому же формату, не будет возникать никаких сюрпризов.
Подробнее о политиках, например, о политиках сборки библиотек, политике альтернатив и т. п. см. раздел политики сборки пакетов.Заголовок Spec-файла содержит важную информацию, необходимую для сборки, о версии пакета, исходном коде, патчах, зависимостях.
В начале Spec-файла содержатся определения макросов. Например:
%define major 0 %define libname %mklibname aide %{major}
Все %define должны быть определены именно в этом месте с соответствующими комментариями. Для выравнивания макроопределений используется табуляция как показано выше (используйте двойную табуляцию после определения name или столбец 25 (конец третьей табуляции); это позволит использовать более длинные имена в определениях). Если имя определения длиннее и следующий символ табуляции будет находиться за 26-й колонкой, используйте одиночный пробел, например:
TODO: привести данный пример
Первый раздел должен содержать стандартное название, версию и тэг релиза:
Name: aide Version: 0.13.1 Release: 1
Следующий раздел заголовка должен выглядеть следующим образом:
Summary: Advanced Intrusion Detection Environment License: GPLv2+ Group: Monitoring URL: http://sourceforge.net/projects/aide Source0: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz Source1: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz.asc Source2: aide.conf Source3: aidecheck Source4: aideupdate Source5: aideinit Source6: aideinit.8 Patch0: some.patch
Как видите, всё располагается в линейном порядке:
Файлы исходников должны начинаться с Source0, не используйте Source:; если в пакете содержится один единственный исходник, используйте Source0, поскольку нет гарантии, что в пакете всегда будет использоваться один исходник. Тоже самое относится к ключевому слову Patch0; всегда начинайте с Patch0:, и никогда не используйте Patch:. Если исходный код имеет URL, по которому его можно получить, то эту информацию необходимо включить.
Табуляции здесь чуть короче, чем определения, главным образом потому, что определения могут быть длиннее, но Source, Name и др. тэгов это не касается. Вместо столбца 25, используйте столбец 17 или конец второй табуляции. Важно, чтобы все значения ключевых слов, и вообще содержимое второй колонки, было выровнено по левому краю, поскольку такое оформление наиболее удобно для чтения.
Патчам должны даваться имена в очень ясной манере, чтобы можно быть быстро понять, какая версия патча была применена и откуда он был взят. Поэтому патчи должны удовлетворять следующему соглашению о наименовании: [название_пакета]-[версия]-[описание].patch:
Далее в spec-файле указываются зависимости сборки - перечень пакетов (или более абстрактных Provides), необходимых для сборки данного пакета. ТАкие зависимости указываются с помощью тэгов BuildRequires. Мы можете в одном тэге указать сразу несколько зависимостей через пробел или запятую, однако для большей читаемости мы рекомендуем указывать в каждом тэге только одну зависимость:
BuildRequires: flex BuildRequires: glibc-devel BuildRequires: glibc-static-devel BuildRequires: mhash-devel BuildRequires: zlib-devel BuildRequires: bison
Последний набор тэгов в заголовке RPM указывает, что пакет предоставляет (тэг Provides; такие предоставляемые возможности можно потом указывать в тэгах Requires и BuildRequires других пакетов), какие пакеты он делает устаревшими (тэг Obsoletes), с какими пакетами конфликтует (тэг Conflicts) и от каких зависит (тэг Requires); обратите внимание, что в скобках после этого тэга можно дополнительно указывать ключевые слова post-, pre- и так далее, если зависимость требуется для выполнения соответствующих скриптов).
Requires: gnupg Requires(pre): foo Requires(postun): foo Conflicts: tripwire Provides: AIDE+gpg Obsoletes: bar
Для удобства, мы рекомендуем не мешать разные тэги, а следовать определенному порядку:
Тэг %description находится в самом конце, в нём содержится описание пакета. Длина строки должна составлять 76 символов.
В итоге, RPM-spec должен выглядеть следующим образом:
Name: aide Version: 0.13.1 Release: 1 %define major 0 %define libname %mklibname aide %{major} %define somereallylongname foo Summary: Advanced Intrusion Detection Environment License: GPLv2+ Group: Monitoring URL: http://sourceforge.net/projects/aide Source0: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz Source1: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz.asc Source2: aide.conf Source3: aidecheck Source4: aideupdate Source5: aideinit Source6: aideinit.8 Patch0: some.patch Buildrequires: flex BuildRequires: glibc-devel BuildRequires: glibc-static-devel BuildRequires: mhash-devel BuildRequires: zlib-devel BuildRequires: bison Requires: gnupg Requires(pre): foo Requires(postun): foo Conflicts: tripwire Provides: AIDE+gpg Obsoletes: bar %description AIDE (Advanced Intrusion Detection Environment) is a free alternative to Tripwire. It does the same things as the semi-free Tripwire and more. It is a file system integrity monitoring tool.
Для пакетов, которые создают несколько подпакетов, следуйте выше изложенному руководству для каждого подпакета.
Раздел %prep находится после всех определений пакета. По крайней мере 2 пустые строки должны отделять конец раздела %description от %prep. Простейший раздел %prep выглядит следующим образом:
%prep %setup -q
Системные макросами являются макросы, определённые в файлах Шаблон:Файл - например, %make, %makeinstall_std и др. Системный макрос - это нечто выполняющее что-либо или вычисляющее что-либо. Т. е. системный макрос это не простое определение, например как %{_tmppath}, которое просто переводит путь. Системные макросы записываются без фигурных скобок, например, %mkrel, а не %{mkrel}. Макросы, определённые пользователем, которые включают в себя %{_tmppath} или %{_bindir} записываются в фигурных скобках, например, %{_tmppath}, а не %_tmppath. Если все будут использовать данное соглашение о фигурных скобках, это упростит чтение spec-файла.
Если вы не уверены, использовать ли фигурные скобки, помните, что макросы, подобные %{_libdir}, отдают значение (в данном случае, Шаблон:Файл), в то время как макрос, подобный %_install_info, действительно выполняет некоторый код.
При условии использования сходных названий для макросов повышается читабельность spec-файла.
Переменные, которые действительно являются переменными, например $RPM_OPT_FLAGS или $RPM_BUILD_ROOT, не должны использоваться. Вместо них должны использовать макросы, подобные %{optflags} и %{buildroot}. Переменные "$*" относятся к конструкциям оболочки, но не к RPM-определениям.
Журналы изменений хранятся в журналах Git. При выполнении коммита в Git журнал становится частью итогового spec-файла (т. к. журналы коммита создают журнал изменений RPM во время сборки). Делайте записи в журнале достаточно подробными, чтобы позднее не приходилось использовать diff ддя просмтра изменений. Пример плохой записи в журнале:
- fixed foo
Подобная запись ни о чём не говорит и, кто бы ни сделал это изменение, он не сможет сказать, что же было сделано в этом коммите. Вместо этого нужно было записать что-то в этом духе:
- переработан description.patch для новой версии foo - добавлен foo-manpages.tar.bz2, предоставляющий то-то и то-то - удален cvsfix32.patch (перенесе в апстрим)
Такая запись в большей степени информирует о сделанных изменениях. Заметьте, что исходники должны ссылаться на свои полные имена (как в примере: вместо S23 используется длинное имя foo-manpages.tar.bz2). Патчам нет необходимости ссылаться на полные имена, но могут ссылаться на часть описания патча. Например, первый комментарий "переработан description.patch для новой версии foo", может относиться к патчу с именем foo-1.2-rosa-description.patch. Префикс foo-1.2-rosa можно опустить, если нет других патчей со словом "description" в содержательной части имени. Если же есть два похожих патча (например, foo-1.2-rosa-description.patch и foo-1.0-cvs-description.patch), то ссылка на "description.patch" в комментарии будет неоднозначна; таких ситуаций следует избегать.
Ни в коем случае не ссылайтесь в комментариях на патчи или файлы исходного кода по их номерам в spec-файле (то есть Source2 или Patch3), поскольку патчи и файлы могут появляться и исчезать. нумерация - изменяться, и спустя некоторое время по комментариям будет невозможно понять, что собственно изменялось.
Файлы исходного кода обычно обрабатываются макросом %{SOURCExx}, но это неэффективно по нескольким простым причинам:
Вместо, в spec-файле предпочтительно использовать %{_sourcedir}/foo, т. к. это упрощает чтение файла. Например, сравните:
Source12: something ... install -m 0644 %{SOURCE12} %{buildroot}%{_sysconfdir}/pam.d/
с:
Source12: something.pam ... install -m 0644 %{_sourcedir}/something %{buildroot}%{_sysconfdir}/pam.d/
Файлы исходного кода не должны содержать макросов %{version} и %{name}, если только они не являются оригинальными файлами исходного кода из апстрима.
Файлы патчей никогда не должны содержать макросов %{version} и %{name}.