Мне также непонятно отсутствие макросов для сборки растовской части.

Можете объяснить как вы собирали этот пакет?

(Ответ для Сергей Жидких на комментарий #2)
> Можете объяснить как вы собирали этот пакет?

В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как данный пакет собирался в других дистрибутивах.

(Ответ для Сергей Жидких на комментарий #1)
> Мне также непонятно отсутствие макросов для сборки растовской части.

Прошу простить мою некомпетентность в данном вопросе как человеку, проходящему join. Будет исправлено в следующей сборке.

(Ответ для Сергей Жидких на комментарий #0)
> https://www.altlinux.org/Shared_Libs_Policy

А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В upstream-е wasmtime уже поднимался issue по поводу soname в 2021 году(https://github.com/bytecodealliance/wasmtime/issues/2996).
На текущий момент, насколько я знаю, проблема не решена(хоть issue и закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api привязана к версии самого wasmtime.
В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и определённых гарантий с версионированием основного проекта в отношение API wasmtime-c-api.

Как возможные варианты решения проблемы:
1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования ABI в wasmtime-c-api во второй раз. Возможно приложив PR.
2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI на человека X, которым могу выступить и я, когда руки дойдут до использования в своём личном проекте.

Но эти решения требуют определённого времени, так что сразу предложу временные варианты решения:
1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562).
2. Использовать в качестве soname полную версию пакета. Данный вариант уже собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354).

Эти два временных варианта - две крайности, которые не решают настоящую проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy.

(Ответ для kiper на комментарий #3)
> (Ответ для Сергей Жидких на комментарий #2)
> > Можете объяснить как вы собирали этот пакет?
> 
> В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как
> данный пакет собирался в других дистрибутивах.

Вы пробовали собирать без RUST_MIN_STACK? Если разработчик явно не указал требование к размеру стека при сборке, значит переполнение стека может указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые пакеты периодически падали при сборке.

> (Ответ для Сергей Жидких на комментарий #1)
> > Мне также непонятно отсутствие макросов для сборки растовской части.
> 
> Прошу простить мою некомпетентность в данном вопросе как человеку,
> проходящему join. Будет исправлено в следующей сборке.
> 
Спасибо. Обратите также внимание на используемую лицензию, она имеет дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0 with LLVM-exception" по названию используемому в cargo.toml. Можете в качестве примера взять https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/

> (Ответ для Сергей Жидких на комментарий #0)
> > https://www.altlinux.org/Shared_Libs_Policy
> 
> А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В
> upstream-е wasmtime уже поднимался issue по поводу soname в 2021
> году(https://github.com/bytecodealliance/wasmtime/issues/2996).
> На текущий момент, насколько я знаю, проблема не решена(хоть issue и
> закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api
> привязана к версии самого wasmtime.
> В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и
> определённых гарантий с версионированием основного проекта в отношение API
> wasmtime-c-api.
> 
> Как возможные варианты решения проблемы:
> 1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования
> ABI в wasmtime-c-api во второй раз. Возможно приложив PR.
> 2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI
> на человека X, которым могу выступить и я, когда руки дойдут до
> использования в своём личном проекте.
> 
> Но эти решения требуют определённого времени, так что сразу предложу
> временные варианты решения:
> 1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и
> CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562).
> 2. Использовать в качестве soname полную версию пакета. Данный вариант уже
> собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354).
> 
> Эти два временных варианта - две крайности, которые не решают настоящую
> проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy.
Спасибо за развёрнутый ответ, было очень полезно узнать про проблемы растовских C-подобных библиотек. Очень плохо что upstream не понимает назначение soname.

Оба временных решения являются плохими. Если разработчики не понимают для чего нужен soname, значит и гарантий что будет однозначное соответствие между C API и версией пакета нет. В таком случае ручное задание soname будет надёжнее.

Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на сотрудничество, то заниматься версионированием самостоятельно.

(Ответ для Сергей Жидких на комментарий #4)
> Вы пробовали собирать без RUST_MIN_STACK? 

Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом была рекомендация.

> Если разработчик явно не указал
> требование к размеру стека при сборке, значит переполнение стека может
> указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые
> пакеты периодически падали при сборке.

Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача #392457

> Спасибо. Обратите также внимание на используемую лицензию, она имеет
> дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку
> у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0
> with LLVM-exception" по названию используемому в cargo.toml. Можете в
> качестве примера взять
> https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/

Благодарю. Возьму на заметку и исправлю!


> Оба временных решения являются плохими. Если разработчики не понимают для
> чего нужен soname, значит и гарантий что будет однозначное соответствие
> между C API и версией пакета нет. В таком случае ручное задание soname будет
> надёжнее.

Согласен с вами.

> Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на
> сотрудничество, то заниматься версионированием самостоятельно.

Так и поступлю.

(Ответ для kiper на комментарий #5)
> (Ответ для Сергей Жидких на комментарий #4)
> > Вы пробовали собирать без RUST_MIN_STACK? 
> 
> Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом
> была рекомендация.
> 
> > Если разработчик явно не указал
> > требование к размеру стека при сборке, значит переполнение стека может
> > указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые
> > пакеты периодически падали при сборке.
> 
> Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача
> #392457

Этап сборки прошёл. Ошибки переполнения стека не произошла. 
Благодарю за информацию!

﷐[U+1F44D]﷑