On Tue, 9 Nov 2021 12:59:17 GMT, Andrew Leonard <aleon...@openjdk.org> wrote:
> This PR adds a new openjdk build tool GenerateZip, which generates a final > "zip" file from an input folder, and creates it in a deterministic way, > ensuring ordering and timestamps are set as specified. > > Using this tool in ZipArchive.gmk will ensure src.zip is then created > deterministically. > > Signed-off-by: Andrew Leonard <anleo...@redhat.com> We already have an --enable-reproducible-builds. If (and I say if) we need to turn this on/off with a flag, this would to fine. However, as I have said previously in a private discussion with Andrew, I prefer it if we can make reproducible builds so cheap, reliable and uncontroversial so we can always to reproducible builds, and remove that flag. For this case, I think it depends on two things: 1) the extra time to make the zip file reproducible. Some benchmarking on the GenerateZip for src.zip would be good to have, at least for some ballpark figures. 2) When is src.zip built? (I don't remember right now) If it is part of the exploded-image, then it is really time sensitive (and should maybe move out of that target). If it part of the jdk-image, I'd say it is not as sensitive, due to a) this is very much slower anyway, and b) that part is much more parallelizible, so src.zip can be produced while waiting for jlink or whatever. Also, the name is not really a correct description at this point. Maybe a straight `MakeZipReproducible` instead or something like that? And have you verified that running with `zip -X` is not enough? I remember checking into this before, but I don't remember the conclusions. The purpose is to leave out some extra information, such as time stamps, but it might not be enough to guarantee reproducible builds. ------------- PR: https://git.openjdk.java.net/jdk/pull/6311
