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