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, либо форкать его и делать так, как мы хотели бы. -- Anton Zhukharev ALT Linux Team