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

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

[Anton Farygin]

On 9/15/26 15:55, Rx wrote:
>
>
>           Для добавления возможности вендоринга spec-файл должен
>           содержать:
>
> # При отключенном вендоринге брать vendor/ из заранее подготовленного 
> архива.
> %{!?_enable_rust_vendoring: Source1: vendor.tar }
>
> BuildRequires(pre): rpm-build-rust
> # При активном вендоринге, установить программу для вендоринга.
> # По умолчанию %rust_vendor использует cargo-vendor-alt из 
> cargo-vendor-filterer.
> %{?_enable_rust_vendoring:
> BuildRequires: cargo-vendor-filterer
> }
>
> %prep
> # Аналогично Source1.
> %setup %{!?_enable_rust_vendoring:-a1}
> %rust_prep
>
Т.е. для вендоринга внутри hasher нужна сеть, соответственно это не 
сработает без специальным образом запущенного hasher.

Очень похоже на python, но там понятно когда расползаются зависимости, а 
здесь забытый вендоринг про себя что-то скажет ?

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

[Ivan A. Melnikov]

On Wed, Sep 16, 2026 at 12:11:13PM +0300, Rx wrote:
> 15.09.2026 16:39, Anton Farygin пишет:
> > On 9/15/26 15:55, Rx wrote:
> > > 
> > > 
> > >           Для добавления возможности вендоринга spec-файл должен
> > >           содержать:
> > > 
> > > # При отключенном вендоринге брать vendor/ из заранее
> > > подготовленного архива.
> > > %{!?_enable_rust_vendoring: Source1: vendor.tar }
> > > 
> > > BuildRequires(pre): rpm-build-rust
> > > # При активном вендоринге, установить программу для вендоринга.
> > > # По умолчанию %rust_vendor использует cargo-vendor-alt из
> > > cargo-vendor-filterer.
> > > %{?_enable_rust_vendoring:
> > > BuildRequires: cargo-vendor-filterer
> > > }
> > > 
> > > %prep
> > > # Аналогично Source1.
> > > %setup %{!?_enable_rust_vendoring:-a1}
> > > %rust_prep
> > > 
> > Т.е. для вендоринга внутри hasher нужна сеть, соответственно это не
> > сработает без специальным образом запущенного hasher.
> 
> Альтернативой было бы монтирование локального зеркала внутрь hasher или
> установка нескольких сотен noarch/srpm в сборочную среду. В любом из этих
> случаев нужна автоматизация на уровне Spec-файла.
> 
> А так предложенный подход ничем ни отличается от Packaging/Vendoring
> <https://www.altlinux.org/Packaging/Vendoring>. Единственное отличие это
> уход от полностью ручного запуска вендоринга к запуску вендоринга при помощи
> средств RPM. По-моему мнению это неплохое начало для того, чтобы в будущем
> можно было отказаться от вендоринга целиком.
> 
> > Очень похоже на python, но там понятно когда расползаются зависимости, а
> > здесь забытый вендоринг про себя что-то скажет ?
> 
> За соотвестивием зависимостей следит Cargo, особенно если при сборке будет
> указан --locked или --frozen:
> 
> error: no matching package named `adler2` found
> location searched: directory source `/usr/src/RPM/BUILD/resvg-0.48.1/vendor`
> (which is replacing registry `crates-io`)
> required by package `miniz_oxide v0.8.9`
>     ... which satisfies dependency `miniz_oxide = "^0.8"` (locked to 0.8.9)
> of package `png v0.18.1`
> note: offline mode (via `--frozen`) can sometimes cause surprising
> resolution failures
> help: if this error is too confusing you may wish to retry without
> `--frozen`
> error: Bad exit status from /usr/src/tmp/rpmb-tmp.LiwVrM (%build)
> 
> Если речь в поддержании зависимостей в свежем состоянии, то это больше
> вопрос к сборочной инфраструктуре. На текущий момент из всех пакетов которые
> я смотрел от разных мейнтейнеров повторный вендоринг с более
> свежими**зависимостями был в одном или двух пакетах, и то, я предполагаю это
> связано с исправлением ошибки в Cargo в решателе зависимостей, которая
> привела к падению. В идеальном мире, повторный вендоринг нужно делать при
> каждом новом релизе Cargo и при появлении новых версий зависимрстей.
> 
> Надёжных путей решения этой два:
> 
>  1.  Мы адаптируем подход Fedora и пакуем несколько тысяч почти никому
>    ненужных пакетов. Таким образом за поддержанием свежести
>    зависимостей следит APT, RPM и Cargo.
>  2.  Мы организуем собственную инфраструктуру вокруг доверенного
>    зеркала и позволяем Cargo перед пересборкой самому решать какие
>    зависимости нужны.
> 
> Первый подход хорош тем, что позволяет автоматизировать установку
> C-библиотек в сборочную среду.

Ещё такие пакеты становятся очевидным местом для применения дистрибутивных
патчей, например обеспечивающих поддержку loongarch64 (ох сколько раз
были пропатчены одни и те же crate в разных пакетах) и e2k. Другой
пример -- исправления, связаные с безопасностью.

> Первым минусом является построение велосипеда
> поверх другого велосипеда, где за совместимостью зависимостей следят два
> инструмента. Вторым минусом является, то что для каждого целевого пакета
> придётся паковать с сотню новых пакетов, на каждую версию целевого пакета,
> не забывая периодически обновлять сборочные зависимости, не забывая при этом
> патчить старые пакеты. Третьим минусом является засорение репозитория
> ненужными пакетами, которые сами по себе имеют очень узкий круг применения,
> например если пользователю обязательно нужно, чтобы все зависимости
> ставились только через apt-rpm.

Такое засорение можно обойти, выделив эти пакеты в отдельный компонент.

> Второй подход хорош тем, что в нём будет проще поддерживать зависимости и
> синхронизацию с основным репозиторием crates.io. Если для некоторых пакетов
> придётся делать отдельные патчи под ALT, будь то уязвимости или поддержка
> сторонних библиотек, можно будет связать эти патчи с конкретным пакетом, а
> не с его десятой разновдиностью. С пользовательской точки зрения доверенное
> зеркало будет куда проще использовать при сборке собственных проектов нежели
> чем при использовании сотен RPM пакетов. Минусом является, то что частичную
> синхронизацию с RPM всё же придётся сделать.
> 
> Тем не менее оба варианта, являются сторонами одной медали, где главное
> отличие это Cargo vs APT/RPM. В любом из случаев нужно будет продумывать
> инфраструктуру, как и что должно работать.


-- 
  wbr,
    iv m.

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

[Artem Semenov]

15.09.2026 15:55, Rx пишет:
>
> Привет!
>
> Недавно нашёл время решить проблемы с которыми сталкивался лично 
> и слышал от других мейнтейнеров при использовании макросов из 
> rpm-build-rust.
>
> Поскольку часть изменений может вызвать споры и непредвиденные 
> побочные эффекты, считаю что стоит поднять обсуждение по возможным 
> доработкам.
>

Предлагаю рационанлизаторское предложение. Раст пакеты, по моему опыту. 
в основном -- как пододеяльник, Т.Е. Вещь в себе, шарит либы не 
используют, все свои зависимости носят с собой., от того они никак не 
связываются между собо й в сизифе.


Предлагаю попробовать рассмотреть на будущее для раст механизмы, похожие 
на xmvn и xgradle, чтобы не вендорить хотябы то, что уже есть в сизифе.

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

[Ivan A. Melnikov]

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.

-- 
  wbr,
    iv m.

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

[Anton Zhukharev]

[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [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.

Re: [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

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

[Anton Zhukharev]

[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]

On Wed, Sep 16, 2026 at 11:36:36AM +0000, Paul Wolneykien wrote:
> 16 сент. 2026, 14:16, Rx написал(а):<br>&gt; 16.09.2026 12:48, Paul Wolneykien пишет:<br>&gt;&gt; ...<br>&gt;&gt;    Мне приходила в голову мысль, что можно было бы собрать в Сизиф<br>&gt;&gt; большие пакеты с названиями вроде rust-deps-best, rust-deps-good,<br>&gt;&gt; rust-deps-bad, rust-deps-ugly и т. д., то есть некоторую "свалку"<br>&gt;&gt; исходников популярных зависимостей, а при сборке пакета просто<br>&gt;&gt; требовать их. В сам же прикладной SRPM вендорить только то, что не<br>&gt;&gt; покрывается этой массой популярных зависимостей. Очевидный минус<br>&gt;&gt; в том, что в сборочную среду будет приезжать большой объём файлов,<br>&gt;&gt; из которых далеко не всё будет использоваться. Но плюс же в том, что<br>&gt;&gt; всё, что собирается таким образом, будет использовать одни и те же<br>&gt;&gt; версии rus-библиотек и несложно будет вести учёт и контроль.<br>&gt; Я думаю это может сработать, но насколько хорошо? Нужен доброволец <br>&gt; который будет этим заниматься. А что если он внезапно исчезнет? <br>&gt; Действительно ли такую свалку будет удобно поддерживать?<br><br>Казалось бы, назвался груздем — полезай в кузов. :) Но только вот я не собрал пока ни одного rust-пакета.<br><br>Поддержку я представляю себе так, что раз в неделю, допустим, прогоняется скрипт, который массово вытягивает новое дерево стабильных исходников и пакует их взамен старых. То есть, как вендоринг, но в особо крупных размерах. И чейнджлог составляется: "были обновлены такие-то пакеты". К этому нужно добавить возможность ставить на холд некоторые версии — не заменять их новыми, а держать старые версии рядом с новыми.<br>

Да уж проще вот так раскладывать в одном пакете, например, в случае крейта clap,
который пусть будет, условно, с NEVR = rust-crate-clap-4.5.49-alt1:

%_cratesdir/clap -> symbolic link to clap-4.5.49
%_cratesdir/clap-4.5.49/
%_cratesdir/clap-4.5.48/

и так далее (+ сжимать можно).
И затем указать при сборке в .cargo/config.toml:
```toml
[source.crates-io]
replace-with = "alt-registry"

[source.alt-registry]
directory = "%_cratesdir"
```

Но и тут есть проблема не решенная - например если апстрим пакета сделал
форк для своего проекта и не поменял имя - такое тогда вендорить нужно
будет.


Ну либо прям целый git проекта хранить, но это не на всех будет
распространяться.

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Anton Zhukharev]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On Wed, Sep 16, 2026 at 02:51:57PM +0300, Anton Zhukharev wrote:
> On Wed, Sep 16, 2026 at 11:36:36AM +0000, Paul Wolneykien wrote:
> > 16 сент. 2026, 14:16, Rx написал(а):<br>&gt; 16.09.2026 12:48, Paul Wolneykien пишет:<br>&gt;&gt; ...<br>&gt;&gt;    Мне приходила в голову мысль, что можно было бы собрать в Сизиф<br>&gt;&gt; большие пакеты с названиями вроде rust-deps-best, rust-deps-good,<br>&gt;&gt; rust-deps-bad, rust-deps-ugly и т. д., то есть некоторую "свалку"<br>&gt;&gt; исходников популярных зависимостей, а при сборке пакета просто<br>&gt;&gt; требовать их. В сам же прикладной SRPM вендорить только то, что не<br>&gt;&gt; покрывается этой массой популярных зависимостей. Очевидный минус<br>&gt;&gt; в том, что в сборочную среду будет приезжать большой объём файлов,<br>&gt;&gt; из которых далеко не всё будет использоваться. Но плюс же в том, что<br>&gt;&gt; всё, что собирается таким образом, будет использовать одни и те же<br>&gt;&gt; версии rus-библиотек и несложно будет вести учёт и контроль.<br>&gt; Я думаю это может сработать, но насколько хорошо? Нужен доброволец <br>&gt; который будет этим заниматься. А что если он внезапно исчезнет? <br>&gt; Действительно ли такую свалку будет удобно поддерживать?<br><br>Казалось бы, назвался груздем — полезай в кузов. :) Но только вот я не собрал пока ни одного rust-пакета.<br><br>Поддержку я представляю себе так, что раз в неделю, допуст
> 
> Да уж проще вот так раскладывать в одном пакете, например, в случае крейта clap,
> который пусть будет, условно, с NEVR = rust-crate-clap-4.5.49-alt1:
> 
> %_cratesdir/clap -> symbolic link to clap-4.5.49
> %_cratesdir/clap-4.5.49/
> %_cratesdir/clap-4.5.48/
> 
> и так далее (+ сжимать можно).
Погорячился, вряд ли тут жать можно будет самостоятельно.
Лучше не трогать и оставить эту заботу за RPM.

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Paul Wolneykien]

On Wed, 16 Sep 2026 14:51:57 +0300
Anton Zhukharev wrote:

> On Wed, Sep 16, 2026 at 11:36:36AM +0000, Paul Wolneykien wrote:
> > 16 сент. 2026, 14:16, Rx написал(а):<br>&gt; 16.09.2026 12:48, Paul Wolneykien пишет:<br>&gt;&gt; ...<br>&gt;&gt;    Мне приходила в голову мысль, что можно было бы собрать в Сизиф<br>&gt;&gt; большие пакеты с названиями вроде rust-deps-best, rust-deps-good,<br>&gt;&gt; rust-deps-bad, rust-deps-ugly и т. д., то есть некоторую "свалку"<br>&gt;&gt; исходников популярных зависимостей, а при сборке пакета просто<br>&gt;&gt; требовать их. В сам же прикладной SRPM вендорить только то, что не<br>&gt;&gt; покрывается этой массой популярных зависимостей. Очевидный минус<br>&gt;&gt; в том, что в сборочную среду будет приезжать большой объём файлов,<br>&gt;&gt; из которых далеко не всё будет использоваться. Но плюс же в том, что<br>&gt;&gt; всё, что собирается таким образом, будет использовать одни и те же<br>&gt;&gt; версии rus-библиотек и несложно будет вести учёт и контроль.<br>&gt; Я думаю это может сработать, но насколько хорошо? Нужен доброволец <br>&gt; который будет этим заниматься. А что если он внезапно исчезнет? <br>&gt; Действительно ли такую свалку будет удобно поддерживать?<br><br>Казалось бы, назвался груздем — полезай в кузов. :) Но только вот я не собрал пока ни одного rust-пакета.<br><br>Поддержку я представляю себе так, что раз в неделю, допустим, прогоняется скрипт, который массово вытягивает новое дерево стабильных исходников и пакует их взамен старых. То есть, как вендоринг, но в особо крупных размерах. И чейнджлог составляется: "были обновлены такие-то пакеты". К этому нужно добавить возможность ставить на холд некоторые версии — не заменять их новыми, а держать старые версии рядом с новыми.<br>

  Прошу прощения за HTML. :) Sterna Mail -- в остальном прекрасный
почтовик, но почему-то там не оказалось plain text...


> Да уж проще вот так раскладывать в одном пакете, например, в случае крейта clap,
> который пусть будет, условно, с NEVR = rust-crate-clap-4.5.49-alt1:
> 
> %_cratesdir/clap -> symbolic link to clap-4.5.49
> %_cratesdir/clap-4.5.49/
> %_cratesdir/clap-4.5.48/
> 
> и так далее (+ сжимать можно).
> И затем указать при сборке в .cargo/config.toml:
> ```toml
> [source.crates-io]
> replace-with = "alt-registry"
> 
> [source.alt-registry]
> directory = "%_cratesdir"
> ```
> 
> Но и тут есть проблема не решенная - например если апстрим пакета сделал
> форк для своего проекта и не поменял имя - такое тогда вендорить нужно
> будет.

  Да, в этом случае нужно считать этот форк частью исходников
собираемого пакета. Самое сложное, ИМХО, отследить, когда вдруг такой
форк отделится в самостоятельный проект, который будет иметь смысл
включить в compendium.

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

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 15432 bytes --]

On Wed, Sep 16, 2026 at 12:48:47PM +0300, Paul Wolneykien wrote:
>   Короче говоря, я предлагаю завести и  сопровождать общую (shared)
> базу вендоринга, а в прикладных SRPM вендорить только экзотический
> минимум -- то есть то, что нужно только данной программе и никому
> больше не понадобится. То, что ещё называют compendium.

Как уже заметили другие уважаемые тимовцы, её можно представить:
— как склад всех крейтов всех актуальных версий (в гигапакете, на
сервере...)
— как семейство пакетов в отдельном компоненте, под усл. /usr/src
содержащих распакованные исходники крейтов.

Любая форма, которую может принять такая база вендоринга,
лежит где-то на этой шкале.

On Wed, Sep 16, 2026 at 12:48:47PM +0300, Paul Wolneykien wrote:
> > > On Wed, Sep 16, 2026 at 11:16:11AM +0300, Artem Semenov wrote:  
> > > > Предлагаю попробовать рассмотреть на будущее для раст механизмы, похожие на
> > > > xmvn и xgradle, чтобы не вендорить хотябы то, что уже есть в сизифе.  
>   Мне кажется, что дело не только в возможности использовать системные
> зависимости. Дело в учёте и контроле прежде всего. Вот мы можем как-то
> составить список всех зависимостей (проектов, фреймворков, библиотек,
> rust-пакетов или как они там называются),

"crate".
Бисер^W Ящик!

> которые завендорены среди
> SRPM в Сизифе? Имея такой список его можно дальше оптимизировать.
> Там же наверняка куча всего дублируется. А зачем?

Я тоже считаю, что низачем.
Чтобы подкрепить сей тезис, я тут предпринял попытку оценить количество
повторений для произвольного crate.

https://altlinux.space/arseny/cargo-sofa-analytics

Это (не очень эффективный) скрейпер
/gears и /srpms, его нужно запускать где-нибудь вблизи git.a.o;
например, на сервере team.a.o, аккаунт на котором полагается всем, у
кого есть доступ к gyle.

Для иллюстрации возьмём три сверхпопулярных ящика: 
aho-corasick, anyhow и thiserror.

Например, 6 наиболее популярных вариантов файла aho-corasick/Cargo.toml
на протяжении всех /gears и /srpms с действующей веткой sisyphus
оказались в том или ином vendor-каталоге 837 раз:
    cargo-analytics/. % (export LC_ALL=C; grep -Fr --no-filename aho-corasick/Cargo.toml out | awk '{ NF=3; $1=""; print }' | sort | uniq -c | sort -nr)
>       249  blob c4492a0170b0833a833226479a476d1d9239fb07
>       247  blob dbfa7a9cfdfa00164c4ffba94697672d8c07ae4a
>       152  blob 737f3ef96ccfe89253ee86e0a8442b1ab1435541
>        87  blob c9ad16d2aa5bec52a77f72393913418b6caf7992
>        51  blob 3219bb43cd2627df64eb29a7affc948e38b5b7d9
>        51  blob 1444ce3d1cd37d9133badb158a6ce789f613341a
>         9  blob 62b5f7e12909af6c9b502cae7f0aaf683bcb7a16
>         7  blob f2ebca9b9ba408bff9339acc66edf0560c65904e
>         7  blob 05e899cd4e44e68ff49a53d263220f6974060fdd
>         5  blob d148103d7468b847cfab58e300a51045f777e30c
>         5  blob adf819c504379cc5520f0a360c714ded168906f1
>         4  blob ee8e94e4c0d86a798a6a50b394fcf57ec5545d7e
>         4  blob 344f3e13c8516d78d965253b826fe6b6c7a39067
>         3  blob 412f9b0a70101416dc4b8de512e2bc6ff3cad802
>         2  blob f0abed5ae8152ff6000fcbb2b4cdf6c6a57d4f0e
>         2  blob ef2806914a860e101a73ace48bac41ea7950299c
>         2  blob a6e57b010b2637d5cc2a3cd4789265dbf7218489
>         2  blob a43e8720431ba98ca37b83212f3d5364266f667c
>         2  blob 42926108349d2be24c3ce5f4a5b35b0b75194243
>         2  blob 28d1f7b73cbc7300b7cafbe07c14e8a258b33e99
>         2  blob 0b8a5f5d0d3c85d18b1d24d5dbacac3450699d79
>         2  blob 08e8f3472a8a1a4c2c253a9d16c8525154d96f2a
>         1  blob a0c306a6f291b374e8af037b9b07fc5f52825fa5
>         1  blob 9b8995406bcff2606c1adb027f4f483445b2f5da
>         1  blob 93d5489c7559486e6084023fecb043f61d481b1d
>         1  blob 823a3035ba13e79a3181608395079eeaf388a70d
>         1  blob 6704e30237d042b07f42c9b13f577f8f4bf20220
>         1  blob 610bd4da5dc99f709fed6722c65b7181f1702140
>         1  blob 5c0f4e9bb855ffe5a4031ee2ad0d8cb163dedacb
>         1  blob 4ec45c00b357d8c51c15acaee789d11375a4e984
>         1  blob 38d89ae280bba638a32141c46f97233cf767c283
>         1  blob 06a91f1d0985982fe4c30abdc26a5cb4d39a971f
А варианты этого файла, указанные в git-деревьях 5 или менее раз,
вместе составили всего лишь 47 упоминаний.

Ну и, соотв., аналогичные данные для anyhow и thiserror.
Тот же thiserror, кстати, ещё и присутствует в исходниках другого
довольно популярного derive_more; вендоринг второго порядка.
(далее ещё две пасты и вывод в конце)

>   cargo-analytics/. % (export LC_ALL=C; grep -Fr --no-filename anyhow/Cargo.toml out | awk '{ NF=3; $1=""; print }' | sort | uniq -c | sort -nr)   
>       107  blob e4d2ca8fa51a7118bff269dc66b03f8fdf744e04
>       107  blob e1012e60f1bca7ee2178fcd008ea900e25bc359d
>        78  blob d0b23ccaf79c081a6258755e6cb9b33fdeb1bd8d
>        77  blob 37cdeb7934cc39a1c60e5a16cf2ff0cfa1dbcc8e
>        52  blob f3edfeebdbd2f608c5b9ed859d93cb23122d4ae3
>        51  blob eb949ef0e4344ee18dc01bdb2119233d929ad3b4
>        50  blob 202bc773a5ad96dbd124a7edbb7a2609b46e736d
>        48  blob 79a4ea455222d0d46cb45c96eecab597a7f19f08
>        27  blob 5c24c8ed4c00f586c2769694138e0f06d7e75bc9
>        17  blob 75d9a784a54122a183f2dc11fb3cc60c754d88cc
>        14  blob 85f63a3f6dea87326479a0bcf2beb9228dffb165
>        13  blob e3b9275c2a9448cac80586e95be6bb074a29c4db
>        12  blob 119adf4eec27f6e745ea070267a4e722b193f7fe
>        12  blob 0d6491c13c60ba72b11bd8f54d2d2b98dce8adb2
>        11  blob c06b4c73418251cdb2d4e1d51b0650d7efbf385a
>         7  blob f91b724ad44bdc9bedad1ba2e9144b95454d43c7
>         7  blob f84f27253cf70e579860949141033156dab120f4
>         7  blob ddf007aa86c49f77e31edd7f8adb3ecaaf111248
>         7  blob d42c4704c0292bd8e0f102ae5527bd08ba5040db
>         7  blob 95a8417434643e75431eef7009c6f4a7b254b42f
>         7  blob 83b7f3460913493912c6964c56a2f72d301f5f07
>         7  blob 78bb05953ba2fcc1ebcb67ca0decce4a2fd8bf26
>         6  blob c42ad25bde48e377664007eb79e2a68893911f08
>         6  blob b6d042b4bc18a0440659617e261f1049323edbce
>         6  blob 197d0dc2c30a5944bb72e1007ffdaa6d0aeb986e
>         5  blob b3945b00a0b5497994dd9014db5f3d14e26f9b6d
>         5  blob 9a96fe48b56dd12c8e446b5cb811427d0d0bfac2
>         4  blob 84fed478f68cd8c15f4cd1013d20ae124d62396b
>         3  blob b92e7a329706c3fe040493c2a9ef26e1cbc1ca51
>         3  blob 88be2c2790d6753c27482fc39c20b8c517f41305
>         3  blob 0a4eb7252b41cb6dbf064c3d0e7e363aca1ec976
>         2  blob f6b62357486e90f0d965b2eb24d38c93861bb550
>         2  blob e36ec0221cd0700ffc0d9b750fa677283456ca56
>         2  blob c38246ed7d46cfbdfd8730fb41d9d1e33f2d570b
>         2  blob 6c5516d4cea1f2aedcfdd7877af1684284452f1d
>         2  blob 5909456bbc0012a6b29da179d2f781b41b7544d4
>         2  blob 4b2c7cad14480ce40abf90ec74704a53616cb198
>         2  blob 3a5cce41240703efb29ba8cd0d5359190c4bf3a4
>         2  blob 2f5c8bceb7d2aa2cf12f4b3698987e9803d08f9e
>         2  blob 0cd83c5acb4e46b197c940f9be62fccce1975b19
>         2  blob 09c3dbf1e7ff845289124b21735c89b951fbfae1
>         1  blob fb1350f6932f26157835f7b6b6ecd9ac1fe14a2a
>         1  blob f3ea7c506b25353485763a21cbe1efcc45ce885f
>         1  blob e3f92ee297b72b3727fd69d7603bf851ffd55c1e
>         1  blob d8bb814e636ce4d1d21d274919d6091872423971
>         1  blob d1f3e3efcba3265d934e226c35a13d51ac07edd0
>         1  blob d161d08e23498500d8f730c412270f5b2925071f
>         1  blob c36e376d493230cafbaa34b1bfc8bdb351ad2505
>         1  blob bf9b18f92b03948490b84ac727fabccf0365653f
>         1  blob b16323b024eaba996211b6796709753f29662d81
>         1  blob 952219e8e419d7a55c9d4653e3244624a95a6cdd
>         1  blob 844c2bd3a3f4dce25185880071cc0311b76febf3
>         1  blob 83f27889c7aeab3527f8895712f6d5fdfcea94a5
>         1  blob 7e01b8ee8cd1b1ad1279f718a40258ae9ca5512d
>         1  blob 7959ef1adf49c8c8fd78400906a538fb82cf0977
>         1  blob 757bc1492912464c54fb57ad61afa4146ed64503
>         1  blob 6fca217806724e492ac21223b0f7695a75daee86
>         1  blob 6356b3869561a3e2ecd39bb29a8df569e01ab52f
>         1  blob 494c643618d1babf8433c8fa41092aa570854887
>         1  blob 300334dd5106d21b504c84621983995ad4d2b543
>         1  blob 1aa22dcaf88f2c0cf4e4a402746e557d1ddd399d
>         1  blob 13a1c51e21cd835fef8de73790a49be28f7e1583

>   cargo-analytics/. % (export LC_ALL=C; grep -Fr --no-filename thiserror/Cargo.toml out | awk '{ NF=3; $1=""; print }' | sort | uniq -c | sort -nr)   
>       173  blob 45b51a0c42540b00c836004dc3275f8615ad072a
>       172  blob 8321d4ab0045ec280e65197d8891db5e9f042acc
>        55  blob 59458a18778192aff0c7d4ff6c1faa1e8e3b0582
>        55  blob 28718d7f5b0d1d041915564ab07074d17c71e772
>        50  blob 7203507bfd834ffebd467255c0ed9b56de370ad7
>        50  blob 4e8bf68d70bfab9013d58dcc37a3b23480273863
>        45  blob 39504fe3db9533f923cb75cf3e46b157e7fd44b8
>        39  blob fd4952f91b68eef9f8129df1dc79b4c444622781
>        31  blob 455b950c37079a7c319349b167e777a4ada87179
>        26  blob 8e948da70d1f337c0d2e5526a3cc26b3ad3f583a
>        25  blob 485672ceeb199e9557c256781779ce4554a89475
>        22  blob 9fadb0a3af910edc77747bfd6460e35d266ff952
>        11  blob c921b994fa35299fd7d524aa096cefd0566fd2d9
>        11  blob 0280f356c05fc8f31c924481673286d478bd8665
>        10  blob 2d58539594bb24ea646826214833d75089056202
>        10  blob 0a3ec112778f215a497234fd17096ab585794c99
>         8  blob 052d9b882639ae15d1c7ee6370a7334cfd6fef46
>         6  blob 6d3021ae892bc1f04f8bdf38a9d7970827d79c00
>         5  blob efefc872cebcc3384749f963f2db4a5698b8358e
>         5  blob 6332c27a369df18b2ac7cfefdaefea280a1c35dc
>         5  blob 4c771f00ce7f9a13686828a5647c607c2291adb3
>         5  blob 2c1b4037a30504004cd0c510212bd4722adcc83c
>         4  blob 9cf91cb35311ac23d23aa31519274ae3eb9444bc
>         3  blob dd3403314c6b741cf800fee0ae9e68596cfb99da
>         3  blob db21f8f9dd4210331166fc660d57f652b2575d3a
>         3  blob c4850144a45609c7be1a0826c76c62cd2b719992
>         2  blob e235408d809bf9498da0eaa138f4eb2a5af58810
>         2  blob e1e1a6d7bfeb0e366c00c5f99f85f78b7a58c0f2
>         2  blob d7b215e9be760cbdc5b4f2159f340e0692449c5f
>         2  blob b22f808e28ec7683299718b49a949986a76ea3a2
>         2  blob 983368f8bf48e24d3e225c259cf8b78f5020f4d1
>         2  blob 91425c809990953d52087f52f6e0ce394fa59abd
>         2  blob 7255479278d3001c559c9a86fdcb0cc429f7faef
>         2  blob 71f10086a3e5653b747177c00185157d7141c4cc
>         2  blob 709f2d360ee6cdd2ab4c501241930bebb861b368
>         2  blob 644769f26880f506e1322fe8b91e6737fb9cae79
>         2  blob 608d904d22bb9a33e13b065c9d337d32c61ca221
>         1  blob fed8f7ac2dc57603eddeef9bacb5a5cf3d57a766
>         1  blob fd6cf03e34481e47956756f2b7c6f6c365c94146
>         1  blob fd2d13d14c517a7825b80ac7b87a4735630e9157
>         1  blob edacd09c27854ebeec152677ba7271aeb29fa147
>         1  blob eaab23fe4111a0808a392372a91eda280cebe7dc
>         1  blob da14270cbd2a8c5b8a9136556032f1b45470569e
>         1  blob d3697541967ebee26b6f160cae5693a1f1d87771
>         1  blob c5a699c67766ed749659974b1bd8fcbdc628bc35
>         1  blob c473dce604c3d6b66a9a62a8f1eee5ed163c976c
>         1  blob c0da22ccf98a1fc129bbeda103b653ac60a44a60
>         1  blob bb7315063cc2e69bf7c5f71debe60fddef3253e3
>         1  blob a231faffe706c17e2935e047d88a4636d997ca63
>         1  blob 9666512dade7583fc3a4bd768587fbdc607a027d
>         1  blob 86e24299927ca9d5a27e357cdd0b29d5c8657602
>         1  blob 82a8d666a8de22a7aadef981ebdcbd0ea4ff6fbf
>         1  blob 7d47c7c2f992c762237ab0cb8c4ae51b8ea781f0
>         1  blob 78c99d623b056024e26eb88495a00d2354293360
>         1  blob 78717612420576c4db6077da18e5bf707459871d
>         1  blob 71cf1def1bc57bfec55e6bff0daf3bc46b9d35ec
>         1  blob 5bb5b01d204e230793f513d28c2df38e5bd7925d
>         1  blob 53b073d7661b517f71a8359c71e3250e539ef391
>         1  blob 4ed217390c4320fb798fa96cb8fb1150393b70c3
>         1  blob 4d3905b713a2c7cc2d4e5dea6fa8d432bb51877c
>         1  blob 3064706bc251abfef1befec7453c56e4d3df6538
>         1  blob 2f5e9781ae321eaafbde93b4f1a4e77629748e30
>         1  blob 2f060d6d8f4a8cb7717c5efe0d81bbb40cbfd4b9
>         1  blob 1e1d0cdde9297bb7986e2dd6202c254cc5cae2b5
>         1  blob 093c851e63d91c3231335bf7cdb3d2b64195d1c1
>         1  blob 011dab7e1871ebe33bbf95023f264ae6bffafc47

Я б ещё сделал допущение, что часть внекластерных единиц среди этих
результатов — false positive: незначащие изменения файла привели к
изменению git blob id.
Чтобы дать точную оценку, надо открывать blob в нужном конкретном
репозитории (видимо, по конкретному пути) и его анализировать.

Теперь выводы.
* Инфраструктурный девендоринг в репозитории точно полезен: есть что
  дедуплицировать. Мы однозначно выиграем, если затащим 837 ахокорасиков
  в 6 пакетов (или, может быть, в один пакет со всеми версиями, CAS и
  сжатием).
* Количество версий (V) одного и того же крейта, нужных хотя бы одному
  потребителю, обыкновенно растёт много медленнее, чем кол-во
  потребителей (U) всех версий этого крейта; мы не
  получим U пакетов на крейт, даже если наивно будем класть каждую
  версию в свой пакет.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rx]

16.09.2026 11:31, Ivan A. Melnikov пишет:
> 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, а нужно добавить на них сборочную зависимость и, возможно,
> включить фичу для использования системной библиотеки.

Такое можно сделать, но чтобы принудительно - вряд ли. Всё очень зависит 
от конкретной зависимости.

Можно сделать предупреждение по типу того, которое появляется при elf 
check, но как бы не добавить его только ради того чтобы его потом 
игнорировали.

> Возможно, это стоит делать на уровне cargo-vendor-alt.

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

[Rx]

16.09.2026 11:16, Artem Semenov пишет:
>
> 15.09.2026 15:55, Rx пишет:
>>
>> Привет!
>>
>> Недавно нашёл время решить проблемы с которыми сталкивался лично 
>> и слышал от других мейнтейнеров при использовании макросов из 
>> rpm-build-rust.
>>
>> Поскольку часть изменений может вызвать споры и непредвиденные 
>> побочные эффекты, считаю что стоит поднять обсуждение по возможным 
>> доработкам.
>>
>
> Предлагаю рационанлизаторское предложение. Раст пакеты, по моему 
> опыту. в основном -- как пододеяльник, Т.Е. Вещь в себе, шарит либы не 
> используют, все свои зависимости носят с собой., от того они никак не 
> связываются между собо й в сизифе.

В отдельный случаях Rust пакеты предоставляют C интерфейс, который может 
быть использован другими пакетами, в частности другими Rust пакетами. 
Самый простой пример это yazi и resvg. yazi это простой консольный 
файловый менеджер с поддержкой расширений. Каждое расширение это 
разделяемая библиотека или бинарь и одним из таких расширений является 
resvg, разделяемая Rust библиотека с C-интерфейсом.

Что насчёт использования системных C библиотек, то тут всё грустно: В 
зависимости от апстрима, такая возможность может быть, а может и не 
быть, если она есть то всё зависит от механизма который выбрал апстрим, 
будь это features, cfg или переменные среды.

Тут проще целится на замещающие зависимости.

> Предлагаю попробовать рассмотреть на будущее для раст механизмы, 
> похожие на xmvn и xgradle, чтобы не вендорить хотябы то, что уже есть 
> в сизифе.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Anton Zhukharev]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Wed, Sep 16, 2026 at 09:06:57PM +0300, Rx wrote:
> >  Но я даже не спорю, что, возможно, RUSTFLAGS надо из макросов 
> > убирать, но только не из текущих, а обязательно надо делать это в 
> > новых, намример, каком-нибудь %rust_build_no_flags
> 
> Я бы на самом деле заменил бы приставку rust- на cargo-. При должном 
> желании Rust пакеты могут быть собраны другими системами сборки. 
> Понятно, что де-факто Cargo - главная система сборки, но она не является 
> единственной. Если я правильно помню апстрим Cargo регулярно сслылается 
> на альтернативные системы сборки при разработке нового функционала.

Может, раз уж привязка конкретно к cargo, то делать rpm-build-cargo?
Так было бы, на мой взгляд, справедливее.

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

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

[Paul Wolneykien]

On Thu, 17 Sep 2026 14:01:52 +0300
Danil Shein wrote:

> Вот тут обсуждаются всякие подходы к тому, чтобы втащить в сизиф кучу 
> крэйтов раста как системные зависимости для "контроля и учёта" и вообще 
> всеобщего блага.

  Эту формулировку использовал я, поэтому немного отвечу.

> 
> Идея как будто бы понятная и даже имеющая под собой какое-то обоснование.
> 
> У меня несколько чисто практических вопросов больше с точки зрения 
> разработчика на Раст:
> 
> 1. Как быть с тем что в рамках одного проекта у вас может завендорится 
> сразу несколько несовместимых версий одного и того же крэйта и это 
> вообще абсолютно нормально для экосистемы Раст? Насколько я помню 
> репозиторий такие сценарии поддерживает чуть более чем никак.
> 
> 2. Что буде собой представлять упакеченный крэйт который нужен другим 
> проектам исключительно в виде исходного кода без возможности 
> предварительной компиляции в какие либо артефакты? Просто тарбол с сорцами?

  Я предлагал паковать исходники. Точно так же, как они кладутся в vendor/
или даже .gear/vendor/ в отдельных пакетах сейчас. Фактически, просто
вытащить популярные исходники из "прикладных" пакетов и положить их
в общий *.tar ("compendium"). Технически, это больше дедупликация, чем
что-то ещё. Соответственно, разные версии одного и того же "крэйта"
будут там лежать так же, как они лежали в рамках одного проекта (то
есть, были завендорены при сборке "прикладного" пакета). Мне кажется,
что лежащие по соседству другие исходники им никак не помешают.

  Это ответ на оба вопроса.

  P. S. Я не настоящий сварщик. Принимаю участие в дискуссии в том
числе для того, чтобы более глубоко вникнуть в проблему. Ну и должен
же кто-то глупые вопросы задавать. Это бывает очень полезно. :)

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

[Yuri Sedunov]

В Ср, 28/10/2026 в 10:27 +0300, Rx пишет:
> Просьба к мейнтейнерам пакетов, для которых подготовлены исправления
> выразить явное согласие: 431040

Вышлите мне ваши патчи на почту, пожалуйста.

-- 
Yuri N. Sedunov

[devel] в защиту __cargo (was: Расширение функциональности rpm-build-rust)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

On Wed, Oct 28, 2026 at 10:27:54AM +0300, Rx wrote:
> 
>        По результатам пересборки пакетов картина следующая:
> 
> Из 432 пакетов упало 29:
> phrog   aris - Пакет использует устаревший макрос %__cargo. Исправление:

Здравствуйте!

Я хотел бы предложить оставить макрос __cargo.

Эти бла-бла в начале не просто так; такой макрос по (конечно, не очень
явному) соглашению предназначен для того, чтобы можно было передефайнить
все обращения к %_bindir/cargo в генерируемых скриптах.
Аналогично устроены __make, __ninja,
__mv, __cp, __rm, __install, __chmod, __chown,
__tar, __cpio, __gzip, __bzip2, __xz,
и все остальные.

Оператор может заменить любую из этих утилит на собственную обёртку, на подкоманду в
multi-call binary навроде busybox, на taskset -c, что угодно.

    rpmbuild --define "__tar /usr/local/bin/busybox tar" "$@"
    rpmbuild --define "__ninja taskset -c $(</sys/devices/cpu_atom/cpus) ninja" "$@"
    rpmbuild --define '__make bear -- make' "$@"

Примеры, ясное дело, не исчерпывающие. :)

Первая сотня строк в macros.in так устроена.
https://git.altlinux.org/gitoskop/#/gears/r/rpm-build.git/-/blob/4.0.4.215-alt1/macros.in

Это предусмотренный в подвижной системе дополнительный шарнир:
он нужен не всем и не всегда, но существует.

> phrog-0.53.0-alt2.src.rpm
> <https://git.altlinux.org/tasks/431040/gears/70400/phrog-0.53.0-alt2.src.rpm>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] в защиту __cargo (was: Расширение функциональности rpm-build-rust)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]

On Wed, Oct 28, 2026 at 11:08:02AM +0300, Arseny Maslennikov wrote:
> On Wed, Oct 28, 2026 at 10:27:54AM +0300, Rx wrote:
> > 
> >        По результатам пересборки пакетов картина следующая:
> > 
> > Из 432 пакетов упало 29:
> > phrog   aris - Пакет использует устаревший макрос %__cargo. Исправление:
> 
> Здравствуйте!
> 
> Я хотел бы предложить оставить макрос __cargo.

И, наверное,

    __rustc %_bindir/rustc

тоже нужен, если его вдруг нет.

> Эти бла-бла в начале не просто так; такой макрос по (конечно, не очень
> явному) соглашению предназначен для того, чтобы можно было передефайнить
> все обращения к %_bindir/cargo в генерируемых скриптах.
> Аналогично устроены __make, __ninja,
> __mv, __cp, __rm, __install, __chmod, __chown,
> __tar, __cpio, __gzip, __bzip2, __xz,
> и все остальные.
> 
> Оператор может заменить любую из этих утилит на собственную обёртку, на подкоманду в
> multi-call binary навроде busybox, на taskset -c, что угодно.
> 
>     rpmbuild --define "__tar /usr/local/bin/busybox tar" "$@"
>     rpmbuild --define "__ninja taskset -c $(</sys/devices/cpu_atom/cpus) ninja" "$@"
>     rpmbuild --define '__make bear -- make' "$@"
> 
> Примеры, ясное дело, не исчерпывающие. :)
> 
> Это предусмотренный в подвижной системе дополнительный шарнир:
> он нужен не всем и не всегда, но существует.

Можно, конечно, оставить оба.
"%__cargo" как обозначение "как вызвать программу cargo",
"%cargo" как обращение к прагматике cargo.

Тогда packager сможет, например, сказать:

    rpmbuild --define 'cargo %__cargo auditable' "$@"

и у него заработает всё, что сегодня у вас раскрывает "%cargo".

В любом случае надо это всё задокументировать, чтобы не пропало.

> > phrog-0.53.0-alt2.src.rpm
> > <https://git.altlinux.org/tasks/431040/gears/70400/phrog-0.53.0-alt2.src.rpm>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] в защиту __cargo

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 9642 bytes --]

On Tue, Dec 06, 2005 at 07:52:44PM +0300, Dmitry V. Levin wrote:
> > > Почему?  Одно другого не исключает.  Чрезмерное
> > > употребление макросов снижает читабельность spec-файлов.
> > Тогда было бы неплохо увидеть более официальное обоснование
> > существования %__mv и компании, чем догадки. :)
> %__mv и компания -- это внутренняя кухня rpmbuild, используется
> для запуска mv и компании внутри rpmbuild.
Это утверждение истинно.
Но ведь rpmbuild в тех местах, где он в коде на Си подставляет фрагменты
шелльного текста, мог бы тоже вызывать `mv` словом, без слоя косвенности.
Зачем-то при разработке rpmbuild вставить _такой_ шарнир (i. e. слой косвенности)
понадобилось. Зачем? Полагаю, что чёткий ответ на этот вопрос нам всем
поможет договориться и прочертить границу между чрезмерным и уместным.

Уточню свою мысль.
Например, в пресловутых участках кода rpmbuild можно было бы фрагменты
целиком (или их контекстно малозависимые части) макрообозвать и вытащить
в macros.in. Но почему-то авторы обернули именно пачку утилит. Видимо,
в таких обёртках есть ценность за пределами участков кода rpmbuild.

> Появление этих
> макросов в spec-файлах, видимо, и есть злоупотребление
> макросами.
В спеках явно обращаться к этим __ (т. е. предусматривать перегрузку)
действительно нужно нечасто.
А вот в сложных макрообёртках вроде %cmake, %configure это полезно, и
торчащих зубов __ в спеке не будет.

Если возражение против %__mv было связано только с тем, что у
человеческого читателя спеков дёргается глаз, то избавиться от этого
можно кучей способов, среди которых %define mv __mv, или же просто
забить и писать в спеке по имени. (Там в PATH есть каталог для
обёрток, он стоит первым. Тот, кто желает разок собрать пакет так, чтобы
в окружении были обёртки, может добавить ещё и нагенерить туда обёрток от души.)

On Wed Oct 28, 2026 at 1:43 PM MSK, Rx wrote:
> Здраствуйте!
>
> Первая мысль которая приходит в голову при виде чего либо, что 
> начинается с "_" это то, что это часть внутреннего интерфейса которую 
> стоит трогать только если ты работаешь над ней и знаешь за что она 
> отвечает.  На этот счёт даже есть отдельная старенькая статья  2009-ого 
> TypicalPackagingErrors/InternalMacros 
> <https://www.altlinux.org/TypicalPackagingErrors/InternalMacros>.
Ага. Я забыл про эту страницу :)

> Я подозревал что все макросы с префиксами __ это глобальное 
> переопределение утилит, но насколько глобальные? Было бы неплохо 
> зафиксировать данное соглашение статьёй либо же полноценной политикой.
По итогам обсуждения в сообществе буду готов составить.

> 28.10.2026 11:13, Arseny Maslennikov пишет:
>> On Wed, Oct 28, 2026 at 11:08:02AM +0300, Arseny Maslennikov wrote:
>>> On Wed, Oct 28, 2026 at 10:27:54AM +0300, Rx wrote:
>>>>         По результатам пересборки пакетов картина следующая:
>>>>
>>>> Из 432 пакетов упало 29:
>>>> phrog   aris - Пакет использует устаревший макрос %__cargo. Исправление:
>>> Здравствуйте!
>>>
>>> Я хотел бы предложить оставить макрос __cargo.
>> И, наверное,
>>
>>      __rustc %_bindir/rustc
>>
>> тоже нужен, если его вдруг нет.
> Не особо представляю потребителя данного макроса, сейчас единственным 
> таким потребителем является сам rust. Все остальные вызовы rustc это 
> извлечение версии llvm, хостовой архитектуры и прочей информации которую 
> можно вывести в отдельные макросы.

Потребитель номер раз — ядро Linux (нас это коснётся в конце концов).
Потребитель номер два — с недавних пор systemd.
> - Only the core, alloc and libc crates. Rust code is no_std and there
>   are no other crates. The libc crate isn't needed yet, the bindings
>   generated from the tree's own headers cover libc. And like the
>   kernel we don't use alloc either. Its collections abort when memory
>   runs out. systemd_shared has its own Box and Vec instead, which work
>   like the kernel's: everything that allocates returns an error and
>   there's no global allocator.
> - C linkage only. libsystemd-shared and the dlopen machinery stay as
>   they are. A program written in Rust links libsystemd-shared
>   dynamically just like the C programs do and declares its dlopen()
>   dependencies in .note.dlopen. The Rust crates are linked statically
>   into the programs using them.
> 
> So nothing of the Rust standard library ends up in a program or in
> libsystemd-shared. Per HACKING.md the stripped test-cli-rust binary is
> 32 KB with LTO against 20 KB for its C twin.
https://github.com/systemd/systemd/commit/021112961bd64aec54a1f1e6a6c8fda8b732b705

Я не сомневаюсь, что последуют ещё. :)

>>> Эти бла-бла в начале не просто так; такой макрос по (конечно, не очень
>>> явному) соглашению предназначен для того, чтобы можно было передефайнить
>>> все обращения к %_bindir/cargo в генерируемых скриптах.
>>> Аналогично устроены __make, __ninja,
>>> __mv, __cp, __rm, __install, __chmod, __chown,
>>> __tar, __cpio, __gzip, __bzip2, __xz,
>>> и все остальные.
>>>
>>> Оператор может заменить любую из этих утилит на собственную обёртку, на подкоманду в
>>> multi-call binary навроде busybox, на taskset -c, что угодно.
>>>
>>>      rpmbuild --define "__tar /usr/local/bin/busybox tar" "$@"
>>>      rpmbuild --define "__ninja taskset -c $(</sys/devices/cpu_atom/cpus) ninja" "$@"
>>>      rpmbuild --define '__make bear -- make' "$@"
>>>
>>> Примеры, ясное дело, не исчерпывающие. :)
>>>
>>> Это предусмотренный в подвижной системе дополнительный шарнир:
>>> он нужен не всем и не всегда, но существует.
>> Можно, конечно, оставить оба.
>> "%__cargo" как обозначение "как вызвать программу cargo",
>> "%cargo" как обращение к прагматике cargo.
>>
>> Тогда packager сможет, например, сказать:
>>
>>      rpmbuild --define 'cargo %__cargo auditable' "$@"
>>
>> и у него заработает всё, что сегодня у вас раскрывает "%cargo".
>>
>> В любом случае надо это всё задокументировать, чтобы не пропало.
>
> Если заменить cargo на cargo auditable для всех пакетов и оставить 
> возможность отката на "оригинальный" cargo, то возможно в таком случае 
> есть смысл сохранить макрос, но как будто бы "%define cargo cargo" будет 
> более чем достаточно.

OK, так тоже можно, убедили.
По этому вопросу я амбивалентен; интеллектуальный оператор и так и
так справится, а детерминированную программу, наверное, можно и
подхакать всегда.
Видимо, надо дойти до результата обсуждения выше и тогда решить. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: [devel] в защиту __cargo

[Sergey V Turchin]

On Wednesday, 28 October 2026 13:43:36 MSK Rx Rx wrote:
> Здраствуйте!
> 
> Первая мысль которая приходит в голову при виде чего либо, что
> начинается с "_" это то, что это часть внутреннего интерфейса которую
> стоит трогать только если ты работаешь над ней и знаешь за что она
> отвечает.  На этот счёт даже есть отдельная старенькая статья  2009-ого
> TypicalPackagingErrors/InternalMacros
> <https://www.altlinux.org/TypicalPackagingErrors/InternalMacros>.
> 
> Я подозревал что все макросы с префиксами __ это глобальное
> переопределение утилит, но насколько глобальные?
Обычно префиксом из 2-х подчёркиваний помечается то, что вообще не надо 
трогать или использовать.

[...]

-- 
Regards, Sergey.

Re: [devel] в защиту __cargo

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

On Wed Oct 28, 2026 at 3:55 PM MSK, Sergey V Turchin wrote:
> On Wednesday, 28 October 2026 13:43:36 MSK Rx Rx wrote:
>> Здраствуйте!
>> 
>> Первая мысль которая приходит в голову при виде чего либо, что
>> начинается с "_" это то, что это часть внутреннего интерфейса которую
>> стоит трогать только если ты работаешь над ней и знаешь за что она
>> отвечает.  На этот счёт даже есть отдельная старенькая статья  2009-ого
>> TypicalPackagingErrors/InternalMacros
>> <https://www.altlinux.org/TypicalPackagingErrors/InternalMacros>.
>> 
>> Я подозревал что все макросы с префиксами __ это глобальное
>> переопределение утилит, но насколько глобальные?
> Обычно префиксом из 2-х подчёркиваний помечается то, что вообще не надо 
> трогать или использовать.

Ну вот те, кому не нужно перегружать обращения к утилитам или кто не
знает, зачем им такая перегрузка, и не будут.
:) Будут дёргать porcelain-интерфейс.
Как обычно.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]