| 22 May 2025 |
 emily | -Zbuild-std at least helps… | 09:12:39 |
 K900 | One day we'll have cargo-std-aware | 09:13:08 |
| emily | patch Rust to accept -Zbuild-std on stable, do separate-Rust-crate-packaging, make std one of them 🙃 | 09:13:14 |
| K900 | One day | 09:13:15 |
| emily | it'll be awful with the current Rust packaging scheme. because we would build std for every single application | 09:13:38 |
| emily | oh, I guess not because the FOD is compressed, right? Toma: why do we compress the FOD again? | 12:08:43 |
| emily | anyway, maybe we could move the unpacking of the FOD into the actual Rust package build? | 12:08:54 |
 Alyssa Ross | We'd need to do fetchCargoVendor2 for that | 12:13:56 |
 Toma | It is compressed, because it is how they are downloaded, and it is also not uncompressed so that we don't have file system case sensitiveness bite us with different hashes | 12:13:59 |
| Alyssa Ross | (Which doesn't mean we shouldn't) | 12:14:06 |
| Alyssa Ross | ah right | 12:14:12 |
| emily | fair | 12:16:26 |
| Toma | In reply to @tomasajt:matrix.org
It is compressed, because it is how they are downloaded, and it is also not uncompressed so that we don't have file system case sensitiveness bite us with different hashes Also, just in general, the goal was to have the dumbest possible FOD logic so that under no circumstance will the hash break. | 12:16:29 |
| emily | I think moving it into a hook of the actual build would be good? | 12:16:35 |
| emily | that way nothing gets persisted | 12:16:47 |
| Toma | It would be better. Though we'd need some interesting workarounds...
An interesting option would be to have the non-FOD part jus be a directory with a symlink to the FOD and a marker file that the hook can detect. | 12:19:40 |
