On 20 Nov 2019, at 18:10, Richard Biener <rguenther@suse.de> wrote:
On Wed, 20 Nov 2019, William Brown wrote:
On 20 Nov 2019, at 05:57, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 11/19/19 7:15 PM, Jan Engelhardt wrote:
An alternative would be to devote the manned resources to not grow minute dependencies on large stacks. (That ship has probably sailed in terms of firefox-in-the-distro, (...)
Unless Firefox has changed since the last time I touched the codebase, I'm pretty sure that it has all the Rust crates vendored which it needs. So, Firefox alone shouldn't be a problem.
I think Rust projects will always tend to vendoring, because the huge micro-dependency style system that exists means we'll never keep up trying to package these. Kanidm has ~200 crate indirect dependencies on it's own, I can't imagine how many firefox has. It's a waste of our time to try to package all 200 when we could be putting that time into other things instead. This essentially means we are always at the whims of those vendored dependencies and what they require, and that is highly likely to be the "latest" stable compiler.
I think we should aim to:
* Have rustc/cargo move with the upstream cadence, with automation as suggested into all SLE/LEAP/TW/Other * Do not attempt to package crates - only package leaves IE consuming projects * Improve our rust macros and packaging guides around this topic.
As much as we want to wring our hands and slow down rust, and do things "our way" we can't - we have to follow and adapt in this case.
I wonder whether for packages requiring rust it would be most sensible to package up all dependences into the package itself - that at least ensures a "stable" set of dependences for individual packages even if it means that a dependence might exist twice in different versions in different packages.
Not sure if that also means packaging up their own rust as some package up their own clang/llvm ...
That's what vendoring is - we tar all the dependencies for a package and then build it so suse only needs an up-to-date rustc / cargo in place.
Richard.
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
— 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