Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Fri, 12 Jul 2024 00:23, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>On 7/9/24 06:00, Daniel P. Berrangé wrote:
>> On Tue, Jul 09, 2024 at 02:28:38PM +0200, Paolo Bonzini wrote:
>>> On Tue, Jul 9, 2024 at 2:09 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>>>   * what is the actual baseline requirement? We definitely want
>>>>     to support "using rustup on an older system" (should be no
>>>>     problem) and "current distro building QEMU using the distro's
>>>>     rust", I assume. It would certainly be nice to have "building
>>>>     QEMU on the older-but-still-in-our-support-list distro releases
>>>>     with that distro's rust", but this probably implies not just
>>>>     a minimum rust version but also a limited set of crates.
>>>
>>> I don't think limiting ourselves to the set of crates in the distro is
>>> feasible. It's not the way the language works, for example I tried
>>> checking if the "cstr" crate exists and I didn't find it in Debian.
>> 
>> Yep, Rust is new enough that it is highly likely that crates will be
>> missing in multiple distros.
>> 
>> For ordinary users, cargo will happily download the missing pieces
>> so its not an issue.
>> 
>> For distro packagers, they'll just have to either package up the crates,
>> or bundle them in their QEMU build. Cargo makes the latter easy at
>> least. If distros don't want bundling, they'll need to go the more
>> involved route of packaging deps.
>> 
>> IOW, from a distro POV, IMHO, we should focus on the Rust toolchain
>> versions we need as the minimum bar.
>> 
>> With regards,
>> Daniel
>
>I would like to add that, contrary to pip packages for python, it can be 
>*trusted* that Rust crates.io will keep packages and their different 
>versions, as it was designed to be an immutable registry.
>
>Indeed, users can't remove their package, except for strong security 
>issues, to the opposite of pip.
>
>Besides offline compilation scenario, are there any other reason for 
>wanting to use distro packages instead of letting cargo do the work?

Only distribution packaging is the concern here, where packaged build 
dependencies may be required.