Re: [OE-core] [PATCH v2] gstreamer1.0-plugins-rs: add new package

[Nirbheek Chauhan <nirbheek@centricular.com>]

On Wed, 2026-05-13 at 14:15 +0200, Alexander Kanavin wrote:
> Are these copies listed in Cargo.toml of the plugins? If so, they
> shouldn't be manually specified in SRC_URI, instead they should be in
> the auto-generated gstreamer1.0-plugins-rs-crates.inc, and the build
> process should be able find and use them.

Yes, but only with the plugins published to crates.io. That's how
`cargo publish` works. Tarun is exploring whether to switch to that,
and split this recipe into separate recipes for each plugin.

> There are concerns over discovering and fixing a critical security
> issue in one of the components, when they are vendored into the
> source
> tree this way, all because the compiler team can't settle on an ABI.
> I'm sure you've seen that many times before. The issue is general to
> rust (or node.js or any number of similar approaches to dependency
> management) and not gstreamer-specific, but I still wanted to mention
> it. The problem is, when it happens, it's the integrators that have
> to
> deal with it, not the compiler writers and not the component writers.

Yeah this is a problem for projects that aren't written in Rust, and
this is why Debian ships its own source packages for all the crates,
and they would update / patch those crates independently of what
Cargo.lock says for a project. I don't think that infra exists in Yocto
right now.

Rust projects would just run `cargo audit` and that would recursively
update all crates to fix security vulnerabilities, but that breaks if
you're using Rust to create C libs.

Cheers,
Nirbheek