Buildreq-src: различия между версиями

Материал из ALT Linux Wiki
(Новая страница: «=== Утилита buildreq-src === Это полная копия письма Игоря Власенко https://lists.altlinux.org/pipermail/devel/2016-March/201093.html Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer. Однако так как ранее она уже кочевала из пакета в пакет, ее лучше устанавливать как apt-get install /usr/bin/buildreq-src...»)
 
Нет описания правки
Строка 1: Строка 1:
=== Утилита buildreq-src ===
=== Утилита buildreq-src ===
Это полная копия письма Игоря Власенко [[https://lists.altlinux.org/pipermail/devel/2016-March/201093.html]]
Это полная копия [[https://lists.altlinux.org/pipermail/devel/2016-March/201093.html | письма Игоря Власенко]]




Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer.
Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer.
Однако так как ранее она уже кочевала из пакета в пакет,
Однако так как ранее она уже кочевала из пакета в пакет,ее лучше устанавливать как
ее лучше устанавливать как
 
apt-get install /usr/bin/buildreq-src
apt-get install /usr/bin/buildreq-src


Утилиту можно использовать как при создании пакета,
Утилиту можно использовать как при создании пакета,
так и при сопровождении пакета.
так и при сопровождении пакета.


Создание пакета.
=== Создание пакета ===
_______________


При создании пакета у нас есть только исходники.
При создании пакета у нас есть только исходники. Их и передадим утилите.
Их и передадим утилите.


Это может быть  
Это может быть:


* архив исходников
* архив исходников
buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz
buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz


* каталог с распакованными исходниками
* каталог с распакованными исходниками
buildreq-src ../BUILD/lbreakout2-2.6.5
buildreq-src ../BUILD/lbreakout2-2.6.5


* или даже отдельные файлы:
* или даже отдельные файлы:
buildreq-src ../BUILD/lbreakout2-2.6.5/configure.ac
buildreq-src ../BUILD/lbreakout2-2.6.5/configure.ac


Запустим, к примеру, buildreq-src с архивом исходников.
Запустим, к примеру, buildreq-src с архивом исходников.


$ buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz
$ buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz


утилита выведет найденные сборочные зависимости:
утилита выведет найденные сборочные зависимости:


# BEGIN SourceDeps(oneline):
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel libpng-devel zlib-devel
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel libpng-devel zlib-devel
# END SourceDeps(oneline)
# END SourceDeps(oneline)


Их можно вручную вставить в spec файл.
Их можно вручную вставить в spec файл.
Однако утилита и сама может сделать это, если ей дать еще и spec файл.
Однако утилита и сама может сделать это, если ей дать еще и spec файл.


Сопровождение пакета.
=== Сопровождение пакета ===
_____________________
 
Утилита buildreq-src не работает напрямую c src.rpm пакетом, его надо сначала установить:
rpm -i ../SRPMS/lbreakout2-2.6.5-alt1.src.rpm


Утилита buildreq-src не работает напрямую c src.rpm пакетом.
В gear git репозитории обычно уже ничего делать не нужно, и спек файл, и каталог с распакованными исходниками уже под рукой.
его надо сначала установить:
 
rpm -i ../SRPMS/lbreakout2-2.6.5-alt1.src.rpm
Опять запустим buildreq-src, дополнительно передав ей spec файл опцией --spec <путь>. С опцией --spec buildreq-src только прочитает spec файл.
В gear git репозитории обычно уже ничего делать не нужно,
и спек файл, и каталог с распакованными исходниками уже  
под рукой.


Опять запустим buildreq-src, дополнительно передав
ей spec файл опцией --spec <путь>.
С опцией --spec buildreq-src только прочитает spec файл.
Никаких изменений в spec файле не произойдет.
Никаких изменений в spec файле не произойдет.


buildreq-src --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz  
buildreq-src --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz  


На этот раз утилита выведет более короткий список:
На этот раз утилита выведет более короткий список:


# BEGIN SourceDeps(oneline):
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)
# END SourceDeps(oneline)
 
Этот список -- разность между сборочными зависимостями пакета lbreakout2, найденными утилитой buildreq-src, и сборочными зависимостями пакета, прописанными в его спек файле.
 
Список не пустой --- buildreq-src для lbreakout2 нашла две зависимости для lbreakout2, которые не указаны в спек файле:
 
libSDL_net-devel и zlib-devel.
 
Отсутствие zlib-devel не имело последствий, так как в итоге lbreakout2 все равно слинковался с -lz.


Этот список -- разность между сборочными зависимостями
Ее в итоге вытянула какая-то из других зависимостей. Однако поскольку lbreakout2 явно линкуется с zlib, то zlib-devel лучше добавить в BuildRequires явно.
пакета lbreakout2, найденными утилитой buildreq-src,
и сборочными зависимостями пакета, прописанными в его
спек файле.


Список не пустой --- buildreq-src для lbreakout2
Сегодня она неявно вытягивается по зависимостям, а завтра может и не вытянуться. Тогда сборка сломается, или, что еще хуже, пакет молча соберется но потеряет часть функциональности -- не сможет работать со сжатыми данными.
нашла две зависимости для lbreakout2, которые не
указаны в спек файле: libSDL_net-devel и zlib-devel.


Отсутствие zlib-devel не имело последствий, так как
С libSDL_net-devel проблема немножко серьезнее. lbreakout2 собирается и без libSDL_net-devel,но у lbreakout2 есть режим сетевой игры.для которого libSDL_net-devel и нужен.
в итоге lbreakout2 все равно слинковался с -lz.
Ее в итоге вытянула какая-то из других зависимостей.
Однако поскольку lbreakout2 явно линкуется с zlib,
то zlib-devel лучше добавить в BuildRequires явно.
Сегодня она неявно вытягивается по зависимостям,  
а завтра может и не вытянуться. Тогда сборка сломается,
или, что еще хуже, пакет молча соберется но потеряет
часть функциональности -- не сможет работать
со сжатыми данными.


С libSDL_net-devel проблема немножко серьезнее.
Эту ситуацию я называю недособранным пакетом. В 99% случаев имеющейся функциональности lbreakout2 достаточно, но если вдруг пришли бы к ребенку гости и дети захотели бы попробовать по сети сыграть, то --enable-network был бы кстати.
lbreakout2 собирается и без libSDL_net-devel,
но у lbreakout2 есть режим сетевой игры.
для которого libSDL_net-devel и нужен.


Эту ситуацию я называю недособранным пакетом.
buildreq-src -bp
В 99% случаев имеющейся функциональности lbreakout2 достаточно,
но если вдруг пришли бы к ребенку гости и дети захотели бы
попробовать по сети сыграть, то --enable-network
был бы кстати.


buildreq-src -bp
________________


Имеющиеся патчи могут существенно изменить пакет,
Имеющиеся патчи могут существенно изменить пакет, в частности, поменять его сборочные зависимости. Поэтому имеет смысл запускать утилиту уже на правленные исходники. Для удобства, в buildreq-src есть опция -bp, которая как раз это и делает: вызывает
в частности, поменять его сборочные зависимости.
  pmbuild -bp <name>.spec,
Поэтому имеет смысл запускать утилиту уже на  
правленные исходники. Для удобства, в  
buildreq-src есть опция -bp, которая как раз это  
и делает: вызывает rpmbuild -bp <name>.spec,
затем напускает buildreq-src на %builddir.
затем напускает buildreq-src на %builddir.


$ buildreq-src -bp lbreakout2.spec
$ buildreq-src -bp lbreakout2.spec
Выполняется(%prep): /bin/sh -e /tmp/rpm-tmp.83798
Выполняется(%prep): /bin/sh -e /tmp/rpm-tmp.83798
+ umask 022
 
+ /bin/mkdir -p /home/RPM/BUILD
+ umask 022
+ cd /home/RPM/BUILD
+ /bin/mkdir -p /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ rm -rf lbreakout2-2.6.5
+ cd /home/RPM/BUILD
+ echo 'Source #0 (lbreakout2-2.6.5.tar):'
+ rm -rf lbreakout2-2.6.5
Source #0 (lbreakout2-2.6.5.tar):
+ echo 'Source #0 (lbreakout2-2.6.5.tar):'
+ /bin/tar -xf -
Source #0 (lbreakout2-2.6.5.tar):
+ cd lbreakout2-2.6.5
+ /bin/tar -xf -
+ /bin/chmod -c -Rf u+rwX,go-w .
+ cd lbreakout2-2.6.5
+ exit 0
+ /bin/chmod -c -Rf u+rwX,go-w .
# BEGIN SourceDeps(oneline):
+ exit 0
BuildRequires: libSDL_net-devel zlib-devel
# BEGIN SourceDeps(oneline):
# END SourceDeps(oneline)
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)




Секция BEGIN/END SourceDeps
===Секция BEGIN/END SourceDeps===
___________________________


Если все найденные зависимости уже есть в spec файле,
Если все найденные зависимости уже есть в spec файле, buildreq-src выдаст сообщение  
buildreq-src выдаст сообщение  


buildreq-src: c2050.spec already contains all found dependencies
buildreq-src: c2050.spec already contains all found dependencies


если каких-то зависимостей нет, то они будут выведены в виде
если каких-то зависимостей нет, то они будут выведены в виде


# BEGIN SourceDeps(oneline):
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)
# END SourceDeps(oneline)
 
здесь "# BEGIN SourceDeps(oneline):" и "# END SourceDeps(oneline)" -- волшебные комментарии.


здесь "# BEGIN SourceDeps(oneline):" и "# END SourceDeps(oneline)" --
BuildRequires: libSDL_net-devel zlib-devel,
волшебные комментарии.


BuildRequires: libSDL_net-devel zlib-devel,
которые нашла buildreq-src, можно вставить в lbreakout2.spec руками. Однако если добавить опцию --update (примеры вызова:)
которые нашла buildreq-src, можно вставить  
в lbreakout2.spec руками. Однако если добавить  
опцию --update (примеры вызова:)


buildreq-src --update --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz  
buildreq-src --update --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz  
buildreq-src --update -bp lbreakout2.spec
buildreq-src --update -bp lbreakout2.spec


то buildreq-src вставит в lbreakout2.spec фрагмент
то buildreq-src вставит в lbreakout2.spec фрагмент
# BEGIN SourceDeps(oneline):
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)
# END SourceDeps(oneline)
 
как раз в окружении волшебных комментариев.
как раз в окружении волшебных комментариев.


Эти комментарии очень важны: они позволяют организовать
Эти комментарии очень важны: они позволяют организовать полуавтоматическое обновление сборочных зависимостей пакета. Работает оно следующим образом: без опции --update buildreq-src вообще не трогает пакет. С опцией --update buildreq-src правит только то, что находится между
полуавтоматическое обновление сборочных зависимостей пакета.
 
# BEGIN SourceDeps(oneline):


Работает оно следующим образом: без опции --update
buildreq-src вообще не трогает пакет. С опцией --update
buildreq-src правит только то, что находится между
# BEGIN SourceDeps(oneline):
и  
и  
# END SourceDeps(oneline)
# END SourceDeps(oneline)
 
Все, что вне, считается неприкосновенным.
Все, что вне, считается неприкосновенным.


Как это работает: пусть у нас в lbreakout2.spec вручную вписано
Как это работает: пусть у нас в lbreakout2.spec вручную вписано


BuildRequires: libSDL-devel libSDL_mixer-devel
BuildRequires: libSDL-devel libSDL_mixer-devel
BuildRequires: libpng-devel zlib-devel
BuildRequires: libpng-devel zlib-devel
 
и в новой версии lbreakout2 переехал на libSDL2. Вызовем buildreq-src --update ...утилита вставит в спек новые найденные зависимости
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)


и в новой версии lbreakout2 переехал на libSDL2.
Вызовем buildreq-src --update ...
утилита вставит в спек новые найденные зависимости
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)
но старые устаревшие  
но старые устаревшие  
BuildRequires: libSDL-devel libSDL_mixer-devel
 
BuildRequires: libSDL-devel libSDL_mixer-devel
 
останутся, так как они внесены вручную, а майнтайнер всегда прав.
останутся, так как они внесены вручную, а майнтайнер всегда прав.


Если же в спеке было
Если же в спеке было
# BEGIN SourceDeps(oneline):
 
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel
# BEGIN SourceDeps(oneline):
# END SourceDeps(oneline)
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel
# END SourceDeps(oneline)
 
то после вызова buildreq-src --update ...
то после вызова buildreq-src --update ...
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)
т.е. новые автонайденные зависимости перезапишут собой старые
автонайденные зависимости и старые устаревшие зависимости
libSDL-devel libSDL_mixer-devel удалятся из спека.


В итоге получается
# BEGIN SourceDeps(oneline):
полуавтоматическое обновление сборочных зависимостей пакета.
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)
 
т.е. новые автонайденные зависимости перезапишут собой старые автонайденные зависимости и старые устаревшие зависимости libSDL-devel libSDL_mixer-devel удалятся из спека.
 
В итоге получается полуавтоматическое обновление сборочных зависимостей пакета.
 
=== Формат найденных зависимостей ===
 
По умолчанию,  buildreq-src там, где можно, пытается вывести найденные зависимости в пакетнонезависимом формате, так, как они упоминаются в тексте:


Формат найденных зависимостей.
# BEGIN SourceDeps(oneline):
______________________________
  BuildRequires: /usr/bin/glib-gettextize perl(GD/Text/Wrap.pm) pkgconfig(cairo)
По умолчанию, buildreq-src там, где можно, пытается вывести найденные
# END SourceDeps(oneline)
зависимости в пакетнонезависимом формате, так, как они упоминаются в тексте:


# BEGIN SourceDeps(oneline):
BuildRequires: /usr/bin/glib-gettextize perl(GD/Text/Wrap.pm) pkgconfig(cairo)
# END SourceDeps(oneline)
Это поведение можно изменить, указав   
Это поведение можно изменить, указав   
--sourcedep-resolve=all
 
  --sourcedep-resolve=all
 
или, что то же самое
или, что то же самое
  --sourcedep-resolve=path,perl,pkgconfig
  --sourcedep-resolve=path,perl,pkgconfig
получим более привычные
получим более привычные
# BEGIN SourceDeps(oneline):
BuildRequires: glib2-devel perl-GD-Text libcairo-devel
# END SourceDeps(oneline)


# BEGIN SourceDeps(oneline):
BuildRequires: glib2-devel perl-GD-Text libcairo-devel
# END SourceDeps(oneline)


В следующем письме алгоритм работы утилиты,
 
известные баги и фичи. Содержание:
В следующем письме алгоритм работы утилиты, известные баги и фичи. Содержание:


в силу самого своего алгоритма  
в силу самого своего алгоритма  
buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные,
buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные, лишние зависимости. Как их распознать и как с этим бороться.
лишние зависимости. Как их распознать и как с этим бороться.
 
Как помочь утилите, когда она не справляется.
Как помочь утилите, когда она не справляется.

Версия от 03:50, 2 мая 2022

Утилита buildreq-src

Это полная копия [| письма Игоря Власенко]


Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer. Однако так как ранее она уже кочевала из пакета в пакет,ее лучше устанавливать как

apt-get install /usr/bin/buildreq-src

Утилиту можно использовать как при создании пакета, так и при сопровождении пакета.

Создание пакета

При создании пакета у нас есть только исходники. Их и передадим утилите.

Это может быть:

  • архив исходников
buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz
  • каталог с распакованными исходниками
buildreq-src ../BUILD/lbreakout2-2.6.5
  • или даже отдельные файлы:
buildreq-src ../BUILD/lbreakout2-2.6.5/configure.ac

Запустим, к примеру, buildreq-src с архивом исходников.

$ buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz

утилита выведет найденные сборочные зависимости:

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel libpng-devel zlib-devel
# END SourceDeps(oneline)

Их можно вручную вставить в spec файл.

Однако утилита и сама может сделать это, если ей дать еще и spec файл.

Сопровождение пакета

Утилита buildreq-src не работает напрямую c src.rpm пакетом, его надо сначала установить:

rpm -i ../SRPMS/lbreakout2-2.6.5-alt1.src.rpm

В gear git репозитории обычно уже ничего делать не нужно, и спек файл, и каталог с распакованными исходниками уже под рукой.

Опять запустим buildreq-src, дополнительно передав ей spec файл опцией --spec <путь>. С опцией --spec buildreq-src только прочитает spec файл.

Никаких изменений в spec файле не произойдет.

buildreq-src --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz 

На этот раз утилита выведет более короткий список:

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)

Этот список -- разность между сборочными зависимостями пакета lbreakout2, найденными утилитой buildreq-src, и сборочными зависимостями пакета, прописанными в его спек файле.

Список не пустой --- buildreq-src для lbreakout2 нашла две зависимости для lbreakout2, которые не указаны в спек файле:

libSDL_net-devel и zlib-devel.

Отсутствие zlib-devel не имело последствий, так как в итоге lbreakout2 все равно слинковался с -lz.

Ее в итоге вытянула какая-то из других зависимостей. Однако поскольку lbreakout2 явно линкуется с zlib, то zlib-devel лучше добавить в BuildRequires явно.

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

С libSDL_net-devel проблема немножко серьезнее. lbreakout2 собирается и без libSDL_net-devel,но у lbreakout2 есть режим сетевой игры.для которого libSDL_net-devel и нужен.

Эту ситуацию я называю недособранным пакетом. В 99% случаев имеющейся функциональности lbreakout2 достаточно, но если вдруг пришли бы к ребенку гости и дети захотели бы попробовать по сети сыграть, то --enable-network был бы кстати.

buildreq-src -bp


Имеющиеся патчи могут существенно изменить пакет, в частности, поменять его сборочные зависимости. Поэтому имеет смысл запускать утилиту уже на правленные исходники. Для удобства, в buildreq-src есть опция -bp, которая как раз это и делает: вызывает

 pmbuild -bp <name>.spec,

затем напускает buildreq-src на %builddir.

$ buildreq-src -bp lbreakout2.spec

Выполняется(%prep): /bin/sh -e /tmp/rpm-tmp.83798

+ umask 022
+ /bin/mkdir -p /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ cd /home/RPM/BUILD
+ rm -rf lbreakout2-2.6.5
+ echo 'Source #0 (lbreakout2-2.6.5.tar):'
Source #0 (lbreakout2-2.6.5.tar):
+ /bin/tar -xf -
+ cd lbreakout2-2.6.5
+ /bin/chmod -c -Rf u+rwX,go-w .
+ exit 0
# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)


Секция BEGIN/END SourceDeps

Если все найденные зависимости уже есть в spec файле, buildreq-src выдаст сообщение

buildreq-src: c2050.spec already contains all found dependencies

если каких-то зависимостей нет, то они будут выведены в виде

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)

здесь "# BEGIN SourceDeps(oneline):" и "# END SourceDeps(oneline)" -- волшебные комментарии.

BuildRequires: libSDL_net-devel zlib-devel, 

которые нашла buildreq-src, можно вставить в lbreakout2.spec руками. Однако если добавить опцию --update (примеры вызова:)

buildreq-src --update --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz 
buildreq-src --update -bp lbreakout2.spec

то buildreq-src вставит в lbreakout2.spec фрагмент

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL_net-devel zlib-devel
# END SourceDeps(oneline)

как раз в окружении волшебных комментариев.

Эти комментарии очень важны: они позволяют организовать полуавтоматическое обновление сборочных зависимостей пакета. Работает оно следующим образом: без опции --update buildreq-src вообще не трогает пакет. С опцией --update buildreq-src правит только то, что находится между

# BEGIN SourceDeps(oneline): 

и

# END SourceDeps(oneline)

Все, что вне, считается неприкосновенным.

Как это работает: пусть у нас в lbreakout2.spec вручную вписано

BuildRequires: libSDL-devel libSDL_mixer-devel
BuildRequires: libpng-devel zlib-devel

и в новой версии lbreakout2 переехал на libSDL2. Вызовем buildreq-src --update ...утилита вставит в спек новые найденные зависимости

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)

но старые устаревшие

BuildRequires: libSDL-devel libSDL_mixer-devel

останутся, так как они внесены вручную, а майнтайнер всегда прав.

Если же в спеке было

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel
# END SourceDeps(oneline)

то после вызова buildreq-src --update ...

# BEGIN SourceDeps(oneline):
BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel
# END SourceDeps(oneline)

т.е. новые автонайденные зависимости перезапишут собой старые автонайденные зависимости и старые устаревшие зависимости libSDL-devel libSDL_mixer-devel удалятся из спека.

В итоге получается полуавтоматическое обновление сборочных зависимостей пакета.

Формат найденных зависимостей

По умолчанию, buildreq-src там, где можно, пытается вывести найденные зависимости в пакетнонезависимом формате, так, как они упоминаются в тексте:

# BEGIN SourceDeps(oneline):
BuildRequires: /usr/bin/glib-gettextize perl(GD/Text/Wrap.pm) pkgconfig(cairo)
# END SourceDeps(oneline)

Это поведение можно изменить, указав

 --sourcedep-resolve=all

или, что то же самое

--sourcedep-resolve=path,perl,pkgconfig

получим более привычные

# BEGIN SourceDeps(oneline):
BuildRequires: glib2-devel perl-GD-Text libcairo-devel
# END SourceDeps(oneline)


В следующем письме алгоритм работы утилиты, известные баги и фичи. Содержание:

в силу самого своего алгоритма

buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные, лишние зависимости. Как их распознать и как с этим бороться.

Как помочь утилите, когда она не справляется.