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

Artyom Sinyugin writers на altlinux.org
Чт Сен 17 11:24:25 MSK 2026


В Ср, 16/09/2026 в 21:06 +0300, Rx пишет:
> Мне кажется неправильным безусловно выкидывать RUSTFLAGS

Когда я контрибьютил в rpm-build-rust у меня были точно такие же мысли,
но это не главное. Главное - что из-за первоначальной версии rpm-build-
rust исторически сложилось, что апстримные флаги из config.toml
перезаписываются, следовательно мейтейнерам пришлось где-то
выкручиваться, прописывая нужную логику заново, где-то могли
отключиться апстримные неправильные пути, оптимизации и прочее в нашей
текущей пакетной базе. Честно говоря, можно, конечно, попробовать
пересобрать 100 % зависимых пакетов, но безопасным решением будет не
переписывать кардинально старое, а ввести новые макросы. С вариантами
%cargo_build и пр. норм.  

> > Такой подход позволяет:
> > 
> >    1. Не прибивать вендоринг к наличию дополнительных инструментов,
> >       таких как etersoft-build-utils, zoryn или самописных решений: для
> >       вендоринга достаточно иметь hasher или rpmbuild с программой,
> >       выполняющей вендоринг.
> >    2. Связать процесс вендоринга со spec-файлом.
> >    3. Перевести ручной вендоринг на сторону сборочницы.  Если в будущем
> >       появится подходящая инфраструктура, можно будет заменить
> >       вендоринг обращением к внутреннему зеркалу. 

Вот тут хочется остановиться подробно. Я считаю, три пункта вводят в
заблуждение, так как все три сводятся к одному, как понимаю, к
"заменить вендоринг обращением ко внутреннему зеркалу" когда-то в
будущем (то есть шаг к решению, которого ещё нет). 

Что значит "для вендоринга достаточно иметь hasher или rpmbuild с
программой, выполняющей вендоринг"? Пока нет никаких внутренних зеркал,
до тех пор мы жёстко привязаны к ручному вендорингу. А etersoft, zoryn,
собственные решения с podman или cargo-vendor-filterer - это лишь
вспомогательные инструменты для этого. 

Мысль "связать процесс вендорига со spec-файлом" также жёстко
привязана, как понимаю, к будущему внутреннему зеркалу. 

Если я не прав, поправьте. Если прав, то предлагаю вводить новые
макросы для вендоринга только одновременно с появлением конкретного
решения, зеркал или чего-то такого, чтобы вендор на хостовой системе
ушёл в прошлое окончательно. 

----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20260917/9a43d1b4/attachment.html>


Подробная информация о списке рассылки Devel