SpecTips

Как писать спеки?

Книжки ALT Packaging Maximum RPM (snapshot) http://bog.pp.ru/work/rpm.html Policy

Инструменты buildreq add_changelog

Теги Group License Release BuildRequires

Макросы %setup (*) %origname %trigger* %optflags %changelog %make_install vs. %makeinstall Использование конкретных версий инструментов сборки Как (не) собирать -static пакеты

Разное Скрипты и коды возврата Фильтрация Provides/Requires autoreconf Локализация Одинаковые симлинки в пакетах "Странные" зависимости вида rpmlib(CompressedFileNames) Perl man3 pages TEXTREL Пакетные скрипты, в т.ч. триггеры CFLAGS в qmake Упаковка %files Борьба с TEXTREL Борьба с .la

Примеры

...здесь

Взаимодействие

...здесь

Совместимость

Тут нужно написать о том, как *нужно* делать спеки, как их делать *не* нужно, и все такое.

В частности, многие спрашивают: будет ли спек со стороны работать в альте? Отвечаем: да, скорее всего, но:

а) не обещаем

б) наверняка он не соответствует альтовским правилам, а потому в сизиф не пройдет

Зато на другой вопрос: "будет ли альтовский спек работать где либо еще?", ответ вполне однозначный: в большинстве случаев нет.

Дело это поправимо. Для того, чтобы спек из другого дистрибутива сделать максимально подходящим для ALT, можно использовать команду rpmcs из пакета etersoft-build-utils. Для того, чтобы спек из ALT работал в другом дистрибутиве, там следует установить пакет rpm-build-altlinux-compat. Так же и etersoft-build-utils переносим на другие платформы с помощью этого пакета.

$ fortune ALT -m "наши spec-файлы"
(ALT)
%
На основании этого можно сделать очевидные выводы:
+ нам удобно, чтобы чужие spec-файлы у нас работали (хотя бы для удобства
  подготовки своего spec-файла);
+ нам все равно, будут ли наши spec-файлы работать где-либо еще.
                -- ldv in sisyphus@
%

Обоснование -- у нас "слишком" богатый набор макросов, сопоставимый (по мнению mike@) -- с макросами в PLD и Conectiva. В RedHat и SuSE наборы макросов удивительно бедные, а сами спеки -- очень часто (по всё тому же мнению mike@) жутко кривые. Видимо, это не в последнюю очередь по причине специфической организации сборочных систем и работе майнтейнеров не напрямую со спеками, а с их прообразами?

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

(ldv@ в ALT specfile conventions)

Если нужно просто собрать чужой srpm-пакет, то можно просто взять и
собрать.  FC'шные и MDK'шные пакеты с высокой вероятностью могут собраться
без внесения изменений в spec-файл.  Пакеты из SuSE и PLD более широко
используют свои макросы, возможно, потребуется адаптация.

Если нужно собрать пакет в Сизиф, придётся поработать головой, поскольку
качество чужих spec-файлов в среднем довольно невысокое.

(тоже ldv@)

При этом недавно выяснилось, что не следует использовать в спеках внутренние макросы RPM, которые начинаются с двух подчёркиваний (например, %__install или %__mkdir_p). "А мы и не знали" :-) Скриптик для замены всех %__ на соответственные команды от Michael Shigorin

Ссылки

• Типичные ошибки при написании spec-файлов
• FreeSource:Altlinux/Policy/PackageSplitting

• http://fedora.redhat.com/docs/drafts/rpm-guide-en/
• http://fedoraproject.org/wiki/Packaging/Guidelines
• http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo