On Sun, Mar 12, 2023 at 8:12 AM Jonas Møller via Bug reports for GNU Guix <bug-guix@gnu.org> wrote: > > Hi Guix! The rust.scm file says > > ;;; Note: Only the latest versions of Rust are supported and tested. The > ;;; intermediate rusts are built for bootstrapping purposes and should not > ;;; be relied upon. This is to ease maintenance and reduce the time > ;;; required to build the full Rust bootstrap chain. > ;;; > ;;; Here we take the latest included Rust, make it public, and re-enable tests > ;;; and extra components such as rustfmt. > > And then proceeds to define-public rust as rust-1.60, and I was wondering if > there's any particular reason why a year-old version is used rather than the > 1.65 version. This seems like a mistake, given that the comment claims that > the "latest included Rust" should be made public. > > This is especially troublesome for Rust on Guix because of both how fast its > ecosystem moves onto new language/tooling features, and because using rustup > (the solution for this on other slow-moving distros) relies on pre-built > executables that don't work out-of-the-box on Guix. > > > — Mvh Jonas Møller
Hi Jonas, Is this question in regards to the current or future status of Rust in Guix? Historically, updating Rust has been considered a core-updates level change due to the number of dependent packages [0]. Under the new feature branch workflow there was a recent announcement [1] by the Rust team that 1.67 is in testing [2]. Can Guix's build farm keep up with Rust's six week release cycle? The compute looks to be available but I don't recall a discussion for consideration of storage or a blueprint for pruning old packages. [0] https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html [1] https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00002.html [2] https://ci.guix.gnu.org/jobset/rust-team Greg
