Buildreq
При написании spec-файла возникает необходимость указывать сборочные зависимости в теге BuildRequires. Для упрощения этого процесса в ALT Linux используется специальный скрипт, который называется buildreq и находится в пакете rpm-utils.
Использовать его просто:
$ buildreq example.spec
Скрипт производит почти такую же работу, как и при сборке пакета. В процессе сборки программы он отслеживает все используемые пакеты и в результате добавляет в спек тег BuildRequires с нужными сборочными зависимостями.
Надо сказать, что скрипт не самый совершенный и иногда бывает, что зависимости не очень правильные -- они могут указывать на пакеты совсем не нужные при сборке. В таком случае, выявить и отсеять лишнее вам придется самостоятельно. Другими словами, buildreq производит лишь оценку сверху -- перечисляет достаточные, но необязательно необходимые пакеты.
Также, если в спеке уже прописан тег BuildRequires, то после buildreq он будет удален. Чтобы этого не происходило вам следует использовать тег BuildPreReq. Эти два тега равносильны и единственное отличие состоит в том, что второй не "затирается" при использовании buildreq.
По умолчанию, отслеживаются лишь зависимости для стадий %prep и %build. Это можно изменить ключом -b, указывающим стадию, после которой надо остановиться. Так, -bi указывает, что отслеживать надо стадии %prep, %build и %install.
Date: Tue, 18 Oct 2005 01:10:33 +0400 From: Alexey Tourbin <at@> To: ALT Devel discussion list <devel@> Subject: [devel] Re: webalizer-2.01.10-alt6 On Mon, Oct 17, 2005 at 10:30:28PM +0300, Michael Shigorin wrote: > On Mon, Oct 17, 2005 at 11:23:38PM +0400, Dmitry V. Levin wrote: > > > И что с этим предлагается делать? > > Просто добавить apache-devel в список сборочных зависимостей. > М-да. Даже мысли не допустил, что его там могло не быть... Это известная засада: buildreq "не ловит" файлы в /etc/rpm/macros.d. Workaround: где-нибудь в этих макросах делать stat за пределы /etc/rpm/macros.d. stat будет срабатывать только при раскрытии макросов. В alternatives вроде такое было.
> Интересно зачем для сборки нужен lint? Он там *действительно* > используется? telnet в списке тоже несколько смущает... Для более точного отслеживания нежелательных пакетов можно использовать e.g. buildreq --trace-p=lclint --trace-p=telnet *.spec Полное название опций --trace-package=PKG --trace-file=FILE
Date: Wed, 23 Jul 2008 14:43:51 +0400 From: Alexey Tourbin <at@> To: ALT Linux Team development discussions <devel@> Subject: Re: [devel] firefox unmets (Sisyphus-20080721 x86_64 unmets) On Wed, Jul 23, 2008 at 01:58:17PM +0400, Wartan Hachaturow wrote: > 2008/7/23 Alexey Tourbin: > > В любом случае, зависимость на версию firefox лучше проставлять > > автоматически, а не писать её в ручную. > > [философский вопрос] > > А почему в Сизифе отдаётся предпочтение автоматическому прописыванию > зависимостей? Потому что это единственный технологичный способ получить зависимости у пакетов не ниже определённого качества (а также централизованно управлять политикой выставления зависимостей). А это, в конечном счете, обеспечивает целостность репозитария (работоспособность пакета после установки, или же, напротив, невозможность установить пакет с нарушенными зависимостями). Другими словами, начинающему maintainer'у можно ничего не знать о зависимостях и с ходу собрать пакет, в котором зависимости прописаны правильно. > [Которое ошибается, подвержено глюкам, а порой невозможно вообще]. Оно ошибается гораздо реже, чем человек. Есть определённые типы зависимостей, которые искать действительно сложно -- это, прежде всего, зависимости шелл-скриптов. Это отдельная история. Короче, удалось добиться очень неплохого результата. > Это полезная фича для разаработчика в качестве генерирования исходного > возможного списка зависимостей, но стоит ли результаты её работы > динамически записывать в спек? (В спек ничего не добавляется, добавляется в хедер rpm пакета при его окончательном формировании.) Делать стоит, работает хорошо, на крайний случай отключается, можно дополнять вручную.