On 01/22/2018 05:12 PM, Hadrien Grasland wrote:
The Rust compiler uses unstable internal interfaces, which are not exposed to code which builds on stable releases. The closest equivalent which I can think of in the C/++ world is the GCC/binutils duo: to build and use GCC, you need a matching release of binutils, which maps to a relatively narrow time window. Use too new or too old a release of binutils, and your GCC build will fail with weird assembler and linker errors. And conversely, like any C/++ program, binutils itself has some compiler version requirements.
I'm pretty confident there is never a problem when binutils is too new, at least I haven't run into such a problem with my porting work within Debian. And, furthermore, the key point here again is the speed of change: gcc doesn't introduce breaking changes every six weeks, Rust does.
The problem with Rust is simply the lack of stabilization. It's absolutely insane that they think it's ok to break compatibility in minor versions and it blows my mind that so many people find that acceptable.
Adding features in a minor software release is considered okay in any modern software versioning scheme. It is only when existing features are changed or removed that compatibility is considered to be broken.
I wouldn't consider a toolchain a normal piece of software. A toolchain is one of the basic building blocks of your whole distribution. It shouldn't change in crazy ways when you just perform a minor update.
Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
You must understand where they are coming from. Most Linux distributions consider it okay to ship software which lags 5+ years behind official upstream releases, which is not acceptable for a fast-moving software project like Rust (or even to any software project where new releases matter, such as hardware drivers, web browsers, and office suites). And some of the platforms that they target do not ship a standard package management mechanism at all. The rolling release users among us are sadly the minority here.
Well, your perspective would change if you're responsible for maintaining several hundreds desktop machines with several hundred users. Installing a rolling release distribution in such setups would be a nightmare because you would be busy all day long to fix all kinds of regressions. And I'm not necessarily talking about regressions in the form of bugs. It can already be a regression if feature X behaves differently or extension Y doesn't work anymore. It's really frustrating how many upstream projects are refusing to understand this. So many just say "Awww, just go ahead and update to the latest upstream version, no big deal. I've been running Arch on my single-user, single-machine setup for years without problems." It simply doesn't work that way in the enterprise world.
Rust's distribution tools cater to the vast majority of users who are stuck with obsolete operating system packages and want to get modern work done nonetheless. To do this, they sometimes need to bypass the standard distribution package management scheme. But this need not concern you as a distribution maintainer, much like you need not be concerned about users who build and install more recent software releases from source: what users do with their machine is solely their business, so long as they don't come complain when their personal fiddling breaks the system.
It very much becomes concern if a new version of application X requires an additional of 250 packages to be updated. It becomes a nightmare from a security point of view. Who is going to review all these additional updated packages? What's the point of all these fancy security features Rust have when you end up having 25 different versions of libfoo installed on your system? You might as well then just stop installing security updates. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org