Re: meaning of "Automatic date update in version.in" commits

Matthias Klose
2017-09-21T16:03:26Z

On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 15:25:53 +0200
> Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
>> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
>>> And date stamp in version.in not play here at all. But,
>>>
>>> - if you insert date stamp into sources, you
>>> i) keep "litter" problem
>>> ii) make misorientation (what this date mean? commit date? - it
>>> already
>>> present in commit; and what commit date?)
>>> - if you don't insert date stamp into sources, but add to SONAME
>>> during build process,
>>> it still not reflect ABI compatibilities, but may prevent "binary
>>> reproducible builds"
>>> (depends upon what date you use). I'm underline, that such addition
>>> has no relation to ABI compatibilities, so such SONAME modification
>>> lose sense.
>>
>> Binary reproducible builds mean that if you and I start with the same
>> source code and same build tools, we will get exactly the same build
>> artifacts. Here the build can't "depend on what date you use":
>
> If "date stamp" inserted into binary is a build date, then we will have different
> binaries.

but it not a build date. it is a string taken form a file in the repository.
That's exactly what Simon wrote at the end of the last message, and which you
ignored to read or comment. Please see below.

> If we will use something else, for example "last commit" date,
> then we may have "same" build, but may not. From equality of "last commit" date
> not follow binary equivalence (consider cherry-picked commit, for example,
> or variations of sample "git diff 3110f4be18a2 f625a739" I show above).
>
>> you
>> can't choose a date or another, the date is part of the code you are
>> trying to build. So if you and I build from the same commit, we'll
>> build using the same date, whatever date is in the version.h file.
>>
>>