Summary: | [RFE] backport/implement generate_buildrequires feature | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Stanislav Levin <slev> |
Component: | rpm-build | Assignee: | placeholder <placeholder> |
Status: | NEW --- | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P5 | CC: | arseny, glebfm, imz, ldv, placeholder, vt |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
Stanislav Levin
2023-01-24 16:05:01 MSK
Кто-нибудь может объяснить, какая от этого может быть практическая польза где-либо, помимо autoimports? Конкретная задача в экосистеме Python: автоматизированное управление сборочными зависимостями проекта, которые вычисляются/собираются из различных источников зависимостей (например, pip's reqfile, запрос к сборочному бэкенду (get_requires_for_build_wheel), core metadata и тд). На данный момент изменения в таких источниках отслеживаются человеком вручную при каждом обновлении проекта. Есть несколько вариантов реализации применения зависимостей определенных извне, например: - статический: зависимости заранее вычисляются в подготовленном окружении и сохраняются в файл. Полученный список конвертируется в apt зависимости и применяется к RPM specfile (либо через непосредственное изменение specfile, либо генерация через RPM макрос). pros: - отсутствует зависимость на фичу generate_buildrequires - более наглядный RPM specfile или файл с зависимостями cons: - сборка в несколько этапов (требуется поэтапная генерация зависимостей) - необходимость управления списком зависимостей (менее удобно) - динамический: зависимости вычисляются при сборке src rpm в дереве с исходниками (для этого потребуется установленное средство вычисления и сборочный бэкенд), конвертируются в apt зависимости и добавляются к сборочным зависимостям. pros: - сборка в один этап - нет необходимости управлять списком зависимостей (легче сопровождать) cons: - зависимость от фичи generate_buildrequires - отсутствует наглядность зависимостей в RPM specfile |