Hi Efraim, Efraim Flashner <[email protected]> writes:
> On Tue, Oct 03, 2023 at 11:30:15PM -0400, Maxim Cournoyer wrote: >> Hello, >> >> Ludovic Courtès <[email protected]> writes: >> >> > Hello! >> > >> > Efraim Flashner <[email protected]> skribis: >> > >> >> I tried patching this a couple of ways, but it looks like the best >> >> option is going to be a 'patch-and-repack phase after 'install. the >> >> .crate file is really a gzip tarball, and I suspect that each time we >> >> run 'cargo <something>' the timestamp gets updated. >> > >> > So that ‘Cargo.toml’ file is not something taken from the build tree? >> > In that case we could reset the timestamp before the tarball is >> > created. But otherwise yeah, patch’n’repack. >> >> A better solution would be to have cargo honor SOURCE_DATE_EPOCH, >> perhaps? They'd probably accept such an improvement upstream. > > That'd be an interesting idea, having 'cargo package' set the timestamp > of all the files to SOURCE_DATE_EPOCH. I guess I can look into how > feasible that would be and if they'd be likely to accept a change like > that. > > I have a local patch which unpacks, resets the timestamp and repacks the > crate. I'll definitely push it to the rust-team branch before the next > merge. > > With it I introduced an issue where the 'package phase would repack all > the crates, not just the current one, and ran into our > underscore-to-dash naming convention causing issues with how I'm reusing > the filename to work on the crate. I'll fix that, probably by only > repacking the current crate instead of all crates in the environment. >From past interactions with Rust developers (via their web-based chat system), I could get some change merged rather easily. If you are motivated to fix it cleanly I encourage you to pursue that way! -- Thanks, Maxim
