[devel] Расширение функциональности rpm-build-rust

[Paul Wolneykien]

On Wed, 16 Sep 2026 11:54:48 +0300
Anton Zhukharev wrote:

> On Wed, Sep 16, 2026 at 12:31:48PM +0400, Ivan A. Melnikov wrote:
> > On Wed, Sep 16, 2026 at 11:16:11AM +0300, Artem Semenov wrote:  
> > > 
> > > 15.09.2026 15:55, Rx пишет:  
> > > > 
> > > > Привет!
> > > > 
> > > > Недавно нашёл время решить проблемы с которыми сталкивался лично
> > > > и слышал от других мейнтейнеров при использовании макросов из
> > > > rpm-build-rust.
> > > > 
> > > > Поскольку часть изменений может вызвать споры и непредвиденные побочные
> > > > эффекты, считаю что стоит поднять обсуждение по возможным доработкам.
> > > >   
> > > 
> > > Предлагаю рационанлизаторское предложение. Раст пакеты, по моему опыту. в
> > > основном -- как пододеяльник, Т.Е. Вещь в себе, шарит либы не используют,
> > > все свои зависимости носят с собой., от того они никак не связываются между
> > > собо й в сизифе.
> > > 
> > > 
> > > Предлагаю попробовать рассмотреть на будущее для раст механизмы, похожие на
> > > xmvn и xgradle, чтобы не вендорить хотябы то, что уже есть в сизифе.  
> > 
> > +1
> > 
> > Нужен какой-то механизм, который намекнёт мейнтейнеру, что не нужно
> > не только собирать, но и вендорить исходники какой-нибудь libzstd
> > или openssl, а нужно добавить на них сборочную зависимость и, возможно,
> > включить фичу для использования системной библиотеки.
> > 
> > Возможно, это стоит делать на уровне cargo-vendor-alt.  
> 
> Вообще, cargo-vendor-alt (который является скриптом, который вызывает
> cargo-vendor-filterer) выполняет лишь задачу вендоринга (бандлинга)
> зависимостей с небольшой фильтрацией (в основном по платформам) и в его
> задачи не входит поиск подобных артефактов.
> 
> В целом поиск таких зависимостей - нетривиальная задача, так как помимо
> *-sys библиотек (shared libraries) могут приезжать так же и
> скомпилированные исполяемые файлы (чаще всего встречал protoc), так и
> static libraries. И иногда даже нет никаких ручек (feature или
> переменная окружения) для того, чтобы заставить cargo использовать именно
> системные shared libraries или executables.
> 
> Раз уж хочется использовать системные зависимости то нужно изобретать
> другой механизм, либо контрибьютить в апстрим cargo-vendor-filterer,
> либо форкать его и делать так, как мы хотели бы.

  Мне кажется, что дело не только в возможности использовать системные
зависимости. Дело в учёте и контроле прежде всего. Вот мы можем как-то
составить список всех зависимостей (проектов, фреймворков, библиотек,
rust-пакетов или как они там называются), которые завендорены среди
SRPM в Сизифе? Имея такой список его можно дальше оптимизировать.
Там же наверняка куча всего дублируется. А зачем?

  Мне приходила в голову мысль, что можно было бы собрать в Сизиф
большие пакеты с названиями вроде rust-deps-best, rust-deps-good,
rust-deps-bad, rust-deps-ugly и т. д., то есть некоторую "свалку"
исходников популярных зависимостей, а при сборке пакета просто
требовать их. В сам же прикладной SRPM вендорить только то, что не
покрывается этой массой популярных зависимостей. Очевидный минус
в том, что в сборочную среду будет приезжать большой объём файлов,
из которых далеко не всё будет использоваться. Но плюс же в том, что
всё, что собирается таким образом, будет использовать одни и те же
версии rus-библиотек и несложно будет вести учёт и контроль.

  Правда, я не знаю, можно ли, собирая программу на rust, убедить её
использовать зависимость не с конкретным хэшем (commit id), а соседнюю,
близкую и совместимую версию. Но если можно, тогда всё может получиться.

  Собственно, паковать в rust-deps-* можно не одну версию библиотеки L,
а некоторый диапазон их -- такой набор, который реально нужен для
сборки наших пакетов. А в ситуации, если для сборки программы P нужна
версия L > V, мэйнтейнер P обращается к мэйнтейнеру rust-deps-* с
обоснованной просьбой включить в пакет нужную версию L. Примерно так
же, как сейчас просят обновить либу в Сизифе ("просьба обновить ... для
сборки ..."). И аналогично тому, как мы сейчас в Сизифе избавляемся от
старых версий библиотек ("просьба обновить ваши пакеты ..., чтобы
удалить из Сизифа старую ..."). можно будет внутри rust-deps-*
удалять уже не используемые исходники.

  Короче говоря, я предлагаю завести и  сопровождать общую (shared)
базу вендоринга, а в прикладных SRPM вендорить только экзотический
минимум -- то есть то, что нужно только данной программе и никому
больше не понадобится. То, что ещё называют compendium.