On 2024-08-07 at 18:21:31, Josh Steadmon wrote: > diff --git a/contrib/cgit-rs/Cargo.toml b/contrib/cgit-rs/Cargo.toml > index 7b55e6f3e1..5768fce9e5 100644 > --- a/contrib/cgit-rs/Cargo.toml > +++ b/contrib/cgit-rs/Cargo.toml > @@ -14,3 +14,4 @@ path = "src/lib.rs" > > [dependencies] > libc = "0.2.155" > +home = "0.5.9" Okay, here's where we get to my previous mention of supported platforms. This depends on Rust 1.70, and Debian stable has only 1.63. Trying `cargo build --release` on that version returns this: Downloaded home v0.5.9 Downloaded libc v0.2.155 Downloaded 2 crates (752.3 KB) in 0.17s error: package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.63.0 My recommended approach here is to support the version in Debian stable, plus the version in Debian oldstable for a year after the new stable comes out, which is what I do. That gives people a year to upgrade if they want to use our code. We _don't_ want to follow the latest-stable-Rust approach because it isn't appropriate that software has a six-week lifespan of support and that isn't going to work for software like Git that people often compile locally on older versions. We also need to be conscious that while Rust upstream provides some binaries for some platforms, many platforms rely on the distro packages because Rust upstream doesn't ship binaries for their target. Thus, simply using rustup is not viable for many targets, which is another reason that latest-stable-Rust won't fly. Debian stable is the version that most projects who have defined lifespans track, so it's also what we should track. According to my recommended approach, that would be 1.63. If the Rust project agrees to provide LTS versions, then we can switch to those. In any event, whatever we decide is necessarily going to involve us very carefully planning our dependencies since some crates depend on the latest version whenever it comes out and we're not going to want to do that. I'd also note that we don't actually want the home crate. The README says this: The definition of home_dir provided by the standard library is incorrect because it considers the HOME environment variable on Windows. This causes surprising situations where a Rust program will behave differently depending on whether it is run under a Unix emulation environment like Cygwin or MinGW. Neither Cargo nor rustup use the standard library's definition - they use the definition here. Except that in Git, we _do_ want to honour `HOME` at all times. Thus, the use of the `home` crate instead of the standard library provides exactly the wrong behaviour, and we should remove this dependency. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
