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

[Rx]

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

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

Тем не менее оба варианта, являются сторонами одной медали, где главное 
отличие это Cargo vs APT/RPM. В любом из случаев нужно будет продумывать 
инфраструктуру, как и что должно работать.

> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20260916/2e3de4aa/attachment-0001.html>