RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH
Bernhard M.Wiedemann
github.com+637990+bmwiedemann at openjdk.java.net
Sat Feb 8 11:16:47 UTC 2020
On Fri, 7 Feb 2020 20:04:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>> Do I have to open a separate bug for each of them?
>>
>> Every fix (meaning each pull request) needs a unique bug ID.
>
> As an optional override, I am OK with the concept of having a way for the build to be reproducible.
>
> FWIW, I have scripts that will unpack the modular jar files and diff each class as well as doing the same for a src.zip, and it's pretty easy to tell if only VersionInfo (which is the class that records the time stamps) has changed.
>
> I note that in practice, this is useful for a certain class of builds (e.g., CI or nightly test builds), but each released build is necessarily going to be different because you want a unique time stamp and build number associated with it.
>
> I will review this (probably some time next week) and would like @johanvos to review as well.
> FWIW, I have scripts that will unpack the modular jar files and diff each class
I agree that such specialized diff tools have some value, yet, there are also some limitations and downsides to them. E.g. you cannot simply tell another party what the expected sha256sum of a build result is.
https://www.suse.com/c/?p=42014 also has a section on problems with "the use of specialized comparison tools like [openSUSE's] ‘build-compare‘ "
I probably should write an FAQ entry about that topic...
> each released build is necessarily going to be different because you want a unique time stamp and build number associated with it.
For release builds, it is important that other people can take the released sources and reproduce the same original binaries with the same release number (and ideally same timestamps) to easily verify that the build was clean (not corrupted by bad CPUs/RAM/HDDs or someone messing with the build machine).
I heard, some people even use that to save network bandwidth: add a small patch locally+remotely, build it locally, tell the world the new build hash, but have others upload their binaries with the right hash.
-------------
PR: https://git.openjdk.java.net/jfx/pull/99
More information about the openjfx-dev
mailing list