SpecTips: различия между версиями
Нет описания правки |
|||
Строка 99: | Строка 99: | ||
При этом недавно [http://lists.altlinux.ru/pipermail/devel/2005-December/027129.html выяснилось], что ''не'' следует использовать в спеках ''внутренние'' макросы RPM, которые начинаются с двух подчёркиваний (например, <tt>%__install</tt> или <tt>%__mkdir_p</tt>). "А мы и не знали" :-) | При этом недавно [http://lists.altlinux.ru/pipermail/devel/2005-December/027129.html выяснилось], что ''не'' следует использовать в спеках ''внутренние'' макросы RPM, которые начинаются с двух подчёркиваний (например, <tt>%__install</tt> или <tt>%__mkdir_p</tt>). "А мы и не знали" :-) | ||
[[SpecTips/un|Скриптик]] для замены всех <tt>%__ </tt> на соответственные команды от Michael Shigorin | [[SpecTips/un|Скриптик]] для замены всех <tt>%__ </tt> на соответственные команды от Michael Shigorin | ||
=== Requires: === | |||
<pre>> > Если в req/prov скриптах использовать опцию --verbose, то можно | |||
> > узнать что-нибудь интересное. | |||
> > $ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req -v 2>&1| head | |||
> > shell.req: /usr/bin/add_changelog: cat -> /bin/cat -> ... (via which) | |||
> > shell.req: /usr/bin/add_changelog: /bin/cat -> coreutils (via rpmdb) | |||
> | |||
> Ой хорошо, сегодня только грепал recoll -- где ж он lyx зацепил. | |||
> Кстати, куда кто смотрит, что умудряется вытащить (правильную) | |||
> зависимость на отсутствующий в чруте пакет lyx-qt? | |||
Если собирается хешером, то он смотрит в | |||
$build/cache/contents/contents_index_bin. | |||
Этот contents index как раз нужен, чтобы лучше искать зависимости вопреки | |||
минимальной сборочной среде и в ряде случаев давать более точные | |||
зависимости, напр. зависимость на mutt должна разрешиться в /usr/bin/mutt, | |||
а не в mutt или mutt1.5, т.к. любой из них сгодится. | |||
Кстати я внес много исправлений в find-package (это типа диспетчер, как искать | |||
такого рода зависимости), теперь в ряде "сложных" случаев | |||
результат будет более корректным. См. commit messages, там есть примеры | |||
с /sbin/ifup, openssl-config, arpsend и vim.</pre> | |||
''[http://lists.altlinux.org/pipermail/devel/2007-March/042883.html at@]'' | |||
=== Ссылки === | === Ссылки === | ||
* [[TypicalPackagingErrors|Типичные ошибки]] при написании spec-файлов | * [[TypicalPackagingErrors|Типичные ошибки]] при написании spec-файлов |
Версия от 01:47, 17 августа 2008
Как писать спеки?
Книжки |
Инструменты |
Теги |
Макросы |
Разное |
Примеры
...здесь
Взаимодействие
...здесь
Совместимость
Тут нужно написать о том, как *нужно* делать спеки, как их делать *не* нужно, и все такое.
В частности, многие спрашивают: будет ли спек со стороны работать в альте? Отвечаем: да, скорее всего, но:
- а) не обещаем
- б) наверняка он не соответствует альтовским правилам, а потому в сизиф не пройдет
Зато на другой вопрос: "будет ли альтовский спек работать где либо еще?", ответ вполне однозначный: в большинстве случаев нет.
Дело это поправимо. Для того, чтобы спек из другого дистрибутива сделать максимально подходящим для 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
Requires:
> > Если в req/prov скриптах использовать опцию --verbose, то можно > > узнать что-нибудь интересное. > > $ rpm -ql rpm-utils |file -NF$'\t' -f - |/usr/lib/rpm/shell.req.files |/usr/lib/rpm/shell.req -v 2>&1| head > > shell.req: /usr/bin/add_changelog: cat -> /bin/cat -> ... (via which) > > shell.req: /usr/bin/add_changelog: /bin/cat -> coreutils (via rpmdb) > > Ой хорошо, сегодня только грепал recoll -- где ж он lyx зацепил. > Кстати, куда кто смотрит, что умудряется вытащить (правильную) > зависимость на отсутствующий в чруте пакет lyx-qt? Если собирается хешером, то он смотрит в $build/cache/contents/contents_index_bin. Этот contents index как раз нужен, чтобы лучше искать зависимости вопреки минимальной сборочной среде и в ряде случаев давать более точные зависимости, напр. зависимость на mutt должна разрешиться в /usr/bin/mutt, а не в mutt или mutt1.5, т.к. любой из них сгодится. Кстати я внес много исправлений в find-package (это типа диспетчер, как искать такого рода зависимости), теперь в ряде "сложных" случаев результат будет более корректным. См. commit messages, там есть примеры с /sbin/ifup, openssl-config, arpsend и vim.
Ссылки
- Типичные ошибки при написании spec-файлов
- FreeSource:Altlinux/Policy/PackageSplitting