Re: [opensuse-packaging] On how to improve Rust packaging experience for suse
On 19 Nov 2019, at 20:43, Alberto Planas Dominguez <aplanas@suse.com> wrote:
On Tuesday, November 19, 2019 12:58:35 AM CET William Brown wrote:
That is funny, because I set myself to help (inside my modest skills) on both projects (Rust and Kanidm) before this issue arise. As usual I am too late.
Never too late, would always be happy to have your input and advice :)
Anyways.
For opensuse I can probably do something like adding devel:languages:rust as a respository to my project. Would this strategy be viable on SLE? What about for projects which we want to expose packages for fedora or other? Are we able to have toolchains move faster than our base system?
I have a naive TODO:
1) Add in _service, script and / or document how to update rustc, and help the rustc maintaner in the update task more pro-actively
2) Add _service, script and document the upgrade of the crates, helping the work that the Fedora guys are doing in openSUSE. I think that is time for openSUSE to help here.
2.5) Research how the Haskel team is doing their magic, as IMHO is a good example to follow.
3) Using some data-driven mechanism, decide the crates / version will live in TW and the ones that will live only in the devel project. I am not sure how to tackle the multiversioning here.
I hope to automatize all the steps, and do the submit to TW incrementally, as I am worried about the legal review.
The compiler (and crates) in Leap and SLE cannot follow this peace, but we can help upstream to crystallize the idea of 'reference / stable compiler version'. Maybe we can skip 3 / 4 versions form TW to one in Leap.
For SLE we can use the backports. The managers can interlock later the version for SLE, based on the requirements on the software that they are shipping.
For Kanidm (and any project that uses Rust) this means that the devel version can compile on TW every day, but for Leap and SLE the version of the project and the compiler cannot change, and the fixes needs to be backported. This is aligned with how every product works: release and backport the fixes.
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.
This can get more complicated with the crates. One usual solution in OBS is to create a subproject for an specific release of the project (lets say, for example, Kanidm 1.0), and link the old version of the crate from devel:languages:rust:crates to the new project.
I'm really looking for ideas on how we can sustainably use rust projects within the governance and social constraints that exist in the space. Ideas?
Neal Gompa wrote:
That said, Fedora and Mageia update the Rust compiler within a week of a new stable compiler release. As of right now, Fedora 29 and higher all have Rust 1.39.0. CentOS/RHEL 7 will receive Rust 1.39.0 soon too[1].
The devel project was updated almost the same day in OBS. We (openSUSE) submitted the new version, created the upstream bug report about the issue that makes impossible the bootstrap of the compiler, and backported it to our packages. I am not going to check Fedora nor Mageia, but if they need to compile 1.39 with 1.38 (and later with 1.39) they need to use this patch.
openSUSE do not have it yet on TW because we recompile all the dependencies, and this 1.39 is having issues with FF[1]. I am not sure if other distributions ship the FF compiled with 1.3X and the rustc from 1.39 independently. We cannot do that: we need to fix the issues as we find them.
Simon Lees wrote:
One reason that it is done like this by default is because core SLE / Leap packages shouldn't be break API/ABI for updates, so in the vast majority of cases building against standard is fine and saves huge amounts of resources on obs.
That is true. But as we cannot have ABI compatibility with rust (not stable ABI and almost all is statically linked), I wonder if this will help to speed the update of the compiler in SLE and Leap.
Neal Gompa wrote:
Rust in openSUSE is mostly community, driven within the Fedora Rust SIG (Yes, Fedora Rust runs the openSUSE Rust stack). The Rust compiler package does get semi-regular contributions from two SUSE employees, but the bulk of the Rust stuff is through the Fedora Rust SIG.
: ? is Luke Jones from Fedora?
But in any case this is 100% true in the crates side. This is almost all done by the excellent Fedora Rust SIG. I really think that it is time for openSUSE to help here and with the upstream scripts from Fedora that is doing this magic.
I want to do my part here.
I think to help (because I want to help here too), we need to think of actionable ways forward. I think we need to think about what rust *should* look like in suse, and work from that vision?
[1] https://build.opensuse.org/project/monitor/openSUSE:Factory:Staging:M? arch_x86_64=1&defaults=0&failed=1&repo_standard=1 -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany
(HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
— 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
On Tuesday, November 19, 2019 1:24:50 PM CET William Brown wrote:
On 19 Nov 2019, at 20:43, Alberto Planas Dominguez <aplanas@suse.com>
For Kanidm (and any project that uses Rust) this means that the devel version can compile on TW every day, but for Leap and SLE the version of the project and the compiler cannot change, and the fixes needs to be backported. This is aligned with how every product works: release and backport the fixes.
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 : ( -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Wed, Nov 20, 2019 at 10:08, Alberto Planas Dominguez <aplanas@suse.de> 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. 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
On 20 Nov 2019, at 19:47, Stasiek Michalski <hellcp@opensuse.org> wrote:
On Wed, Nov 20, 2019 at 10:08, Alberto Planas Dominguez <aplanas@suse.de> 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
On Wed, Nov 20, 2019 at 19:57, William Brown <wbrown@suse.de> wrote:
On 20 Nov 2019, at 19:47, Stasiek Michalski <hellcp@opensuse.org> wrote:
On Wed, Nov 20, 2019 at 10:08, Alberto Planas Dominguez <aplanas@suse.de> 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?
rust2rpm allows us to package crates in minutes, having a script that does that automatically for all the crates with osc sounds fairly simple to do as well. 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
On Wed, 20 Nov 2019, Stasiek Michalski wrote:
On Wed, Nov 20, 2019 at 19:57, William Brown <wbrown@suse.de> wrote:
On 20 Nov 2019, at 19:47, Stasiek Michalski <hellcp@opensuse.org> wrote:
On Wed, Nov 20, 2019 at 10:08, Alberto Planas Dominguez <aplanas@suse.de> 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?
rust2rpm allows us to package crates in minutes, having a script that does that automatically for all the crates with osc sounds fairly simple to do as well.
But then you have CI for Factory and that minutes turn into weeks :P Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Wed, Nov 20, 2019 at 13:04, Richard Biener <rguenther@suse.de> wrote:
On Wed, 20 Nov 2019, Stasiek Michalski wrote:
rust2rpm allows us to package crates in minutes, having a script that does that automatically for all the crates with osc sounds fairly simple to do as well.
But then you have CI for Factory and that minutes turn into weeks :P
That's a downside to QA process, not the packaging issue anymore. As far as I know we are discussing packaging right now, aren't we? 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
Hi, On Wed, 20 Nov 2019, Stasiek Michalski wrote:
On Wed, Nov 20, 2019 at 13:04, Richard Biener <rguenther@suse.de> wrote:
On Wed, 20 Nov 2019, Stasiek Michalski wrote:
rust2rpm allows us to package crates in minutes, having a script that does that automatically for all the crates with osc sounds fairly simple to do as well.
But then you have CI for Factory and that minutes turn into weeks :P
That's a downside to QA process, not the packaging issue anymore. As far as I know we are discussing packaging right now, aren't we?
William (rightly) wants to have something realistic for the distro. Packaging (as in merely creating and submitting packages easily) is only one part, it can't be seen in isolation. If you can submit a thousand packages in 10 minutes doesn't really matter, if those thousand packages then don't land in Factory, or only six months after submission. The whole thing needs to work on all levels. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 20 Nov 2019, William Brown wrote:
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?
A good point indeed.
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?
I see only some ways for the enterprise (or other more stable) distros, and all are terrible: a) bundle rustc itself (not just the other deps) with the packages requiring it. I hear that's what they call "vendoring". b) continously update the one and only rustc compiler in distros (also the enterprise ones). Supposedly rust is backward compatible, so that should continue to be able to compile older sources like librsvg which we might not want to contiously update in the enterprise distros. I would not trust this claim from a community that happily changes language and standard library every six weeks, I don't think they have a mental model of what stability really means. c) provide two rustc compilers in parallel, one remaining stable for building the packages we don't (continously) update and another that quickly updates. Whatever we choose (the only realistic option seems (c) to me), we should make fairly sure that we do _not_ encode any requirements on Rust into base components of our system (librsvg comes to mind, and it is a huge problem that parts are written in Rust; it's a basic component and hinders the Risc-V distro, we have to keep using an old version of libsvg there). It's simply not a good decision to base system components on a quickly changing eco system. In that vain I doubt your choice of using Rust in 389-ds is a very good one; please think hard about the consequences for distros that want to be maintained the next 20 years. You are right that we can't make that choice for other people wanting to use the next fancy language (though we sometimes can in not using what they produce), but you can make that choice for yourself and have to balance the wish for nice language features against the downsides of that eco system. (I personally think requiring an eco system that's only N<4 years old, and is _known_ to change extremely fast, for system components (in comparison to hobby projects or only using it optionally), is actually more than a mere bad choice, it's bordering on irresponsible software design) Ciao, Michael.
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
Hi, On Wed, 20 Nov 2019, Michael Matz wrote:
base components of our system (librsvg comes to mind, and it is a huge problem that parts are written in Rust; it's a basic component and hinders the Risc-V distro, we have to keep using an old version of libsvg there).
Funny story about this in this context: Rust doesn't work on Risc-V because it bundles (vendors, ahem) an old version of llvm. Newer versions of llvm that work on risc-v do exist, but they can't be used in rust easily, because, well, ... the llvm eco-system is changing too fast for them it seems ;-) *sigh* Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Nov 20 2019, Michael Matz wrote:
Funny story about this in this context: Rust doesn't work on Risc-V because it bundles (vendors, ahem) an old version of llvm. Newer versions of llvm that work on risc-v do exist, but they can't be used in rust easily, because, well, ... the llvm eco-system is changing too fast for them it seems ;-)
To clarify, rust master is following the llvm 9 branch, but that isn't ready for RISC-V yet. The llvm master branch fully supports RISC-V now, but that is still a fast moving target. Another issue is that rust depends on the libc crate, which has no support for RISC-V yet, and the arcane rust build system makes it really hard to use a patched crate. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/20/19 11:22 AM, Andreas Schwab wrote:
To clarify, rust master is following the llvm 9 branch, but that isn't ready for RISC-V yet. The llvm master branch fully supports RISC-V now, but that is still a fast moving target. Another issue is that rust depends on the libc crate, which has no support for RISC-V yet, and the arcane rust build system makes it really hard to use a patched crate.
Their CI also can make adding these changes really tiresome, I have been trying to add the target sparc-unknown-linux-gnu to the libc crate for a month now [1]. Adrian
On 11/20/19 11:07 AM, Michael Matz wrote:
Funny story about this in this context: Rust doesn't work on Risc-V because it bundles (vendors, ahem) an old version of llvm. Newer versions of llvm that work on risc-v do exist, but they can't be used in rust easily, because, well, ... the llvm eco-system is changing too fast for them it seems ;-)
Actually, in Debian, the rustc package uses the LLVM package from the system and in my experience this works reasonably well these days. I don't actually know why no one has added the risc64-unknown-linux-gnu spec to Rust upstream yet, but if no one is going to do that until the end of the year, I'm going to do that during the Christmas holidays. Otherwise, I fully agree with what you said in your previous mail. We have already had the same discussion in Debian. It caused so much traction, it was actually in the news on LWN [1] ;). Debian's librsvg maintainer uploaded the rustified version of the library just after I managed to bootstrap the Rust compiler on all release architectures in Debian [2] which was the result of a lot of debugging and bug fixing. I actually felt betrayed because I'm also one of the maintainers of most unofficial architecture ports in Debian (Debian Ports), so I was not particularly amused about this upload. If Rust upstream finally realized that a stable language and API isn't just some archaic and pointless construct, the language would certainly receive a much wider adoption with alternative compiler implementations being available. Adrian
[1] https://lwn.net/Articles/771355/ [2] https://lists.debian.org/debian-devel-announce/2018/11/msg00000.html
On Nov 20 2019, John Paul Adrian Glaubitz wrote:
Actually, in Debian, the rustc package uses the LLVM package from the system and in my experience this works reasonably well these days. I don't actually know why no one has added the risc64-unknown-linux-gnu spec to Rust upstream yet,
Probably because llvm9 doesn't work yet on riscv. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/20/19 12:43 PM, Andreas Schwab wrote:
On Nov 20 2019, John Paul Adrian Glaubitz wrote:
Actually, in Debian, the rustc package uses the LLVM package from the system and in my experience this works reasonably well these days. I don't actually know why no one has added the risc64-unknown-linux-gnu spec to Rust upstream yet,
Probably because llvm9 doesn't work yet on riscv.
But Rust upstream has already riscv support, just not for the linux-gnu ABI. Adrian
Hi, On Wed, 20 Nov 2019, John Paul Adrian Glaubitz wrote:
On 11/20/19 12:43 PM, Andreas Schwab wrote:
On Nov 20 2019, John Paul Adrian Glaubitz wrote:
Actually, in Debian, the rustc package uses the LLVM package from the system and in my experience this works reasonably well these days. I don't actually know why no one has added the risc64-unknown-linux-gnu spec to Rust upstream yet,
Probably because llvm9 doesn't work yet on riscv.
But Rust upstream has already riscv support, just not for the linux-gnu ABI.
The difference that Andreas meant is between llvm9 branch (where the support is not complete enough) and master (where it sort of is). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Nov 20 2019, John Paul Adrian Glaubitz wrote:
But Rust upstream has already riscv support, just not for the linux-gnu ABI.
There is a lot of room between cross and native support. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz schrieb:
[...] Whatever we choose (the only realistic option seems (c) to me), we should make fairly sure that we do _not_ encode any requirements on Rust into base components of our system (librsvg comes to mind, and it is a huge problem that parts are written in Rust; it's a basic component and hinders the Risc-V distro, we have to keep using an old version of libsvg there). It's simply not a good decision to base system components on a quickly changing eco system.
Is the C librsvg still ABI compatible? If so, I'd love to have it back in the distro, at least for building. That would avoid having the stack above rsvg waiting for rust and llvm to build. That's a whole working day. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 247165 (AG München) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Nov 20 2019, Ludwig Nussel wrote:
Is the C librsvg still ABI compatible?
It still uses the same soname, but of course, that doesn't tell much. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 11/20/19 10:08 AM, Alberto Planas Dominguez wrote:
Vendoring can only be a temporary workaround until the crate ecosystem become more stable in OBS : (
You make it sound like as if this is a problem on the distribution's side which it isn't. The problem is Rust upstream which is repeating the same mistake that the Python (partially) and NPM communities already made by not guaranteeing stable APIs. Unless Rust makes a change in their policies and keeping their APIs stable, there is little that distributions can do to be able to resolve this issue. You can expect a distribution to update the compiler toolchain and some hundred packages in an LTS branch just because they want to package a new Firefox version. Rust upstream needs to realize that stable APIs are there for a very good reason. In fact, I have talked to main developers from certain upstream projects who told me they would use Rust in their projects if the language and APIs would be more stable. You can't really write fundamental parts of a software stack in Rust if you cannot rely on upstream constantly introducing breaking changes to language and APIs. If you have something like an http server, you want it to be buildable on a large variety of distribution versions and variants. Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Alberto Planas Dominguez -
Andreas Schwab -
John Paul Adrian Glaubitz -
Ludwig Nussel -
Michael Matz -
Richard Biener -
Stasiek Michalski -
William Brown