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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#236976): https://lists.openembedded.org/g/openembedded-core/message/236976 Mute This Topic: https://lists.openembedded.org/mt/119293604/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
