При бэкпорте пакета нередко возникает задача с минимумом итераций сборки выяснить каких сборочных зависимостей не хватает в целевом репозитории. Пересобирать весь список BR:, как мне кажется, неправильно. Также не всегда возможно обновить версию из репозитория источника, когда в этом нет необходимости, а обновление влияет на сборочное окружение других пакетов и требует тщательного тестирования. Запрос, показывающий минимизированный список пакетов точно отсутствующих в целевом репозитории, мог бы быть полезен в такой ситуации для создания сборочного задания без дополнительной локальной пересборки.
Предлагаю подумать о таком варианте: /backport_helper параметры: ветка откуда ветка куда пакеты для переноса или сборочное задание Делаем следующее: берём список сборочных зависимостей переносимых пакетов в ветке "откуда", с учётом версий проверяем наличие этих зависимостей (с учётом версий) в целевой ветке "куда" если нету - добавляем в список переноса и уходим на новый цикл. И так до тех пор, пока список не перестанет расширяться. Зависимости запоминаем, итоговое дерево пакетов сортируем по алгоритму what_depends_src И точно такой же алгоритм должен быть с выбором зависимостей бинарных пакетов переносимых исходных (по аналогии с what_depends_src, нужна возможность указать тип зависимости - binary, source, both). Архитектуру предлагаю по умолчанию использовать x86_64 + noarch как наиболее полную, с возможностью корректировки.
На случай необходимости потестировать: на 01.12.2021 года бэкпорт пакета fwupd из p10 в p9 должен дополнительно потребовать сборки несуществовавших python3-module-smartypants python3-module-typogrify gi-docgen плюс обновления libgusb 0.3.4 -> 0.3.7
*** Bug 41879 has been marked as a duplicate of this bug. ***
Функционал реализован в данном запросе к АПИ: https://rdb.altlinux.org/api/dependencies/backport_helper
