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

[Rx]

16.09.2026 12:48, 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), а соседнюю,
> близкую и совместимую версию. Но если можно, тогда всё может получиться.
Можно, но без вмешательство в Cargo или ослабленния версий в Cargo.toml 
- вряд ли. Проблема только в том, что не во всех частях Rust сообщества 
семантическое версионирование поддерживается на достаточном уровне, 
чтобы точно утверждать о совместимости. Я видел есть какое-то расширение 
для Cargo, которое помогает вести правильное версионирование, но мне 
пока не доводилось его опробовать.
>    Собственно, паковать в rust-deps-* можно не одну версию библиотеки L,
> а некоторый диапазон их -- такой набор, который реально нужен для
> сборки наших пакетов. А в ситуации, если для сборки программы P нужна
> версия L > V, мэйнтейнер P обращается к мэйнтейнеру rust-deps-* с
> обоснованной просьбой включить в пакет нужную версию L. Примерно так
> же, как сейчас просят обновить либу в Сизифе ("просьба обновить ... для
> сборки ..."). И аналогично тому, как мы сейчас в Сизифе избавляемся от
> старых версий библиотек ("просьба обновить ваши пакеты ..., чтобы
> удалить из Сизифа старую ..."). можно будет внутри rust-deps-*
> удалять уже не используемые исходники.
>
>    Короче говоря, я предлагаю завести и  сопровождать общую (shared)
> базу вендоринга, а в прикладных SRPM вендорить только экзотический
> минимум -- то есть то, что нужно только данной программе и никому
> больше не понадобится. То, что ещё называют compendium.
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel