Greetings, I am calling to establish a "default ports rust compiler" version that updates infrequently and only for critical high-profile bugs, such as security fixes. Rust updates far too often and is far too expensive to build, even compared to, say, GCC. I would expect - that anything "normal" in ports that depends on rust can use the "default ports rust compiler", - that the default ports rust compiler only updates once a quarter of a year on average.
That is probably more effort than its worth and to my knowledge upstream only supports the latest version released.
Even if, we don't have a "only latest minor version of compiler" supported policy for the other compilers.
This is an interesting request. Constantly building Rust is a pain.
I apologize if I'm talking nonsense...I don't know if it's possible, but what if a new version of a port depending on rust requires a version higher than the default one? What if the new version of the said port also includes security fixes?
What if a third party port is incompatible with a new Rust compiler? We cannot fix all sorts of misdesigns in architecture and supply chain. We've learned from Node.js that keeping requirements low is a real requirement. You can't just have an eye on 500 recursively pulled in requisites anyways. Rust promises to put an end to security issues, and if a security fix of some third party package really requires the latest and greatest Rust, then I wonder why a security fix itself would raise compiler requirements. Also, in really dire cases either the ports tree will have a rust-latest port or the rust port can be moved in really dire cases. The main idea of this is to reduce the number of rust compiler rebuilds around the world for ports development.
If a project is broken with a new version of compiler, library etc try to work with upstream and/or look at other repos how they've solved it? It's much harder to work the other way around ie fixing by downgrading tools, libraries etc. If there's no solution and we want to move forward just set the port as broken and possibly a deprecation date?
(In reply to Matthias Andree from comment #5) Sorry, I don't mean to argue, it's just out of curiosity... I understand the reasons behind the idea and I'm not particularly happy about upgrading rust. You wrote: "if a security fix of some third party package really requires the latest and greatest Rust, then I wonder why a security fix itself would raise compiler requirements." but with my second question I don't mean that, let me explain with an example: - firefox in ports at 139.0.1 - rust in ports at 1.87.0 is set as default - rust-1.88 is released upstream with new features - firefox-140.0 is released with new features and requires rust-1.88 - firefox-14x.0.1 is relased for a security fix (in it's own codebase, not related to rust) Could the default Rust version be blocking? I'm looking at commit from few hours ago https://cgit.freebsd.org/ports/commit/?id=b0d88ecb8e6e17552bc33ebf1026bf3157664dbb "The dependency on lang/rust-nightly has been changed to lang/rust because Rust 1.87.0 provides the required features for a build." I don't know how many ports rely on the latest and greatest Rust version, but right now, with regular lang/rust updates, there are ports relying on lang/rust-nighly. As a "normal" (I think) ports user, I'm asking: could that increase the chances that more and more ports have to (temporarily) switch their dependency to lang/rust-nighly ending up in having to build not only lang/rust but also lang/rust-nighly?
Good example, thank you. From my industrial-centric perspective (not IT or primarily software industry), requiring the latest-and-greatest toolchain is usually a non-starter. That is because you don't have all the necessary certifications and validations for the latest compiler at that point in time yet, so there'll be a delay until you have all the validations and can actually switch compiler. I would even contend that a package that depends on a non-released aka nightly version of a toolset or toolchain shan't or can't be one that fixes security bugs in its release version and requires a change in its design and release planning. OTOH <https://github.com/PowerShell/PowerShell/issues/10994#issuecomment-572306095> is one of the reasons why I wouldn't want to consider Microsoft a role model, so let's stick to the organizations that seem to act more responsibly, say, Mozilla. What we can learn is that we might want to look at the Cargo.toml and like inputs to figure out the actual Rust requirements across some high-profile ports and see about their Rust requirements - but unfortunately that probably requires downloading and unpacking lots of distfiles.