On Thursday, November 21, 2019 8:40:19 AM CET Richard Biener wrote: [cut a lot here]
From the start of the thread I remember there were two conflicting things - first packaging where vendoring seems to work and while it's not ideal it's probably going to be what we need to do due to being "slow". I interpret your above sentences as that this is intended to work this way.
Then there's the need of a developer using Rust (but not necessarily packaging software for a distro) who wants the latest and greatest. I've suggested we provide means to easily bootstrap such upstream Rust - and you've indicated that yes, indeed, thats supported and even the way it is supposed to work, but there's no openSUSE "package" to start this (in Factor).
What is wrong on the idea of having two compilers: the system one used for the distribution, and the one that can be updated and expected to be used by developers. Another idea is to have one single compiler, the system-wide one, and provide a rustup binary that the developer can use to install rust and cargo on the users $HOME. Dany Marcoux already submitted the package, but later was closed. I personally prefer the 2 compiler idea, tho, but this is irrelevant. [more cut]
Indeed. We're not going to make Rust "go away". Vendoring works fine enough for "leafs" like Firefox but indeed having the rust stack in core components imposes some scalability issues and people should think twice before introducing a rust dependency into, say, systemd. But obviously those who do the work decide, and as alwaks talk is cheap.
I am sorry but... vendoring is not working. OBS is not aware of what is inside, so any security update in any component in the closure can hurt us a lot. We can use vendoring meanwhile the big issue is addressed, but I would never go for this path without a deadline in mind. -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer