Содержание
Единица хранения разработок в репозитории Sisyphus — пакет. Пакет может быть бинарным или с исходным кодом. Формат пакета един для всего репозитория, на данный момент основным форматом является RPM — наиболее распространённый формат пакетов для дистрибутивов Linux. Однако пакеты, предназначенные для Sisyphus, должны отвечать определённым правилам, перечисленным ниже. Прежде всего эти правила касаются написания spec-файлов (файлов описания содержимого пакета и процедур его установки и удаления) — этому посвящён первый раздел. Для решения многих типических задач в ALT Linux Team были разработаны расширения стандартного RPM. Описанию дополнительных возможностей RPM в сборке ALT посвящён следующий раздел. Ряд правил касается операций, которые должны быть произведены в системе в процессе установки и удаления пакета — этому посвящён последний раздел.
При разработке этих правил, а также изменений и дополнений к RPM решались следующие задачи:
Обеспечить желаемую функциональность: Наши пакеты должны отвечать определённым правилам, о которых пойдёт речь несколько позже. Для этого надо, чтобы spec-файлы обеспечивали выполнение этих правил.
Помочь разработчику: Так как spec-файлы все ещё пишут люди, то их работу нужно свести к тому минимуму, который, собственно, и требует участия человека. Разработчик не должен копировать блоки кода из файла в файл, ибо эта неинтеллектуальная работа отнимает массу сил и чревата ошибками. Для этого есть макросы. Если какой-то код появляется в разных spec-файлах более одного раза, то надо написать макрос(ы).
Преобразование оригинального текста в DocBook: Юрий Зотов
Бинарные пакеты собираются под архитектуру i586.
Поле Vendor должно содержать ALT Linux Team.
Обязательно должен присутствовать Changelog с заголовком в формате дата мантейнер его e-mail номер версии и сборки (release).
Обозначение сборки должно быть в формате altномер для новых пакетов и iplномерmdk для старых, переименование со стандарта ipl*mdk на alt* может происходить только при увеличении версии пакета или при переписывании программы заново.
Не следует использовать устаревшие конструкции — они лишь загромождают spec-файл, снижая тем самым его читабельность. К устаревшим конструкциям, в частности, относятся:
тэг BuildRoot;
строки вида rm -rf $RPM_BUILD_ROOT;
%_defattr со стандартными аргументами в начале файлов и секций %files;
секция %clean, пустая либо без разумного содержания.
Нет смысла засорять текст spec-файла ненужными фигурными скобками. Избавиться от них можно с помощью команды cleanup_spec spec-файл .
Используйте символы табуляции для выравнивания. Избегайте пробельных символов в конце строк.
Рекомендуемый порядок заголовочных тэгов: Name, Version, Release, 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-записи используйте утилиту add_changelog spec-файл. Описание изменений должно быть информативным; недостаточно объявить о наличии изменений, необходимо их все явно перечислить.
Если в состав пакета входят файлы локализации либо другие файлы на разных языках, следует использовать макрос %find_lang. Подробную информацию можно получить, выполнив команду /usr/lib/rpm/find-lang -h.
При работе с мультипакетными spec-файлами соблюдайте правило внутрипакетных зависимостей: Если один пакет в какой-либо мере зависит от другого подпакета, то эта зависимость должна быть указана полностью, включая не только имя, но также версию, релиз и serial (если есть). Например,
Requires: %name = %version-%release
или
Requires: %name = %serial:%version-%release.
Обратите внимание на синтаксис: знак равенства, в отличие от дефиса, окружён пробелами.
Пакеты, содержащие как разделяемые библиотеки, так и использующие их программы, должны быть разделены на подпакеты таким образом, чтобы в подпакет, содержащий разделяемые библиотеки, не входили использующие их программы. Это, в частности, позволяет уменьшить количество циклических зависимостей. По традиции, имена пакетов, состоящих только из разделяемых библиотек, должны начинаться с префикса lib либо содержать его внутри слова. При разделении подпакетов следует помнить о внутрипакетных зависимостях.
Каждый пакет, содержащий разделяемые библиотеки в каталоге /lib, /usr/lib или /usr/X11R6/lib, должен их регистрировать при установке/обновлениях и удалении с помощью макросов %post_ldconfig и %postun_ldconfig соответственно.
Статические библиотеки должны паковаться в отдельные подпакеты, что связано со спецификой их использования. Если имя 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*;
проверки на границы (буфера, целых чисел, и т.п.);
патчи, затрагивающие исключительно конфигурационные файлы;
патчи, затрагивающие исключительно configure*;
патчи, затрагивающие исключительно документацию;
кумулятивные патчи и/или исправления по надёжности и/или безопасности;
патчи на использование форматирования строк (printf);
патчи, направленные на возможность выполнения make install непривилегированным пользователем;
патчи, предназначенные для портирования ПО на Linux;
патчи, затрагивающие исключительно man-страницы;
патчи, затрагивающие исключительно документацию в формате texinfo;
патчи, предназначенные для решения различных вопросов, связанных с временными файлами;
патчи, направленные на поддержку vitmp(1);
патчи, исправляющие ошибки, найденные компилятором.
Исходный код большого объёма (как архивы, так и патчи, по статусу приравненные к ним) следует хранить в упакованном виде. Метод сжатия, gzip или bzip2, следует выбирать таким образом, чтобы размер архива был минимальным, например, с помощью утилиты zme. Исключение составляют nosource-пакеты: в них отсутствующие файлы следует указывать в виде корректных URL.