On 20 Nov 2019, at 19:47, Stasiek Michalski
wrote: On Wed, Nov 20, 2019 at 10:08, Alberto Planas Dominguez
wrote: On Tuesday, November 19, 2019 1:24:50 PM CET William Brown wrote:
The issue becomes fixes to vendored dependencies (of which there are ~200 I think total. I directly have ~30 deps). Fixes to kanidm are simple to patch and backport, but fixes for vendored code ... not so much. That's what will really be the issue is rust has no concept of a security update vs a feature one - and most crates treat them as the same - updates. So you will have a vendor library that will both have security *and* feature changes, which will quickly be a maintainers nightmare. Vendoring can only be a temporary workaround until the crate ecosystem become more stable in OBS : (
Granted, somebody would need to use the crates at all, nobody does this far. However 250 and something of them are already in devel:languages:rust:crates.
The crate system will never stabilise - that's the issue - you have hundreds of crates vying to get the latest compiler features, and projects that depend on them, and will set their versions accordingly. And because crates.io / rust has no concept of a security update vs feature update, we'll have to update all the time. If we try to package crates, we'll be forever in a mountain of continual reviews and packaging. But if we just focus on leaf packages which have vendored deps and the compiler, that's much more manageable. We have to focus on value for our time - is it worth our time to be doing the crates? Or the projects that people use? I think it's worth really highlighting *rust is not C*. We can not take our traditional package ideals and apply it to rust else we'll fail. We need to think about this differently. That's my point here. If we can't even keep the compiler up to date with what projects need, how are we going to maintain hundreds of crate versions?
LCP [Stasiek] https://lcp.world
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
— Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org