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

["Ivan A. Melnikov" <iv@altlinux.org>]

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.