bug#50015: Rust packages are not reproducible

[Maxim Cournoyer]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

> On Tue, Oct 03, 2023 at 11:30:15PM -0400, Maxim Cournoyer wrote:
>> Hello,
>> 
>> Ludovic Courtès <ludo@gnu.org> writes:
>> 
>> > Hello!
>> >
>> > Efraim Flashner <efraim@flashner.co.il> 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