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

On Thu, 21 Sep 2017 13:39:08 +0100
Pedro Alves <[email protected]> wrote:

> 
> On 09/21/2017 01:22 PM, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 12:36:46 +0100
> > Pedro Alves <[email protected]> wrote:
> 
> >> I.e., this whole thread feels like the classical XY problem.
> >>
> >> What is the actual problem that you're trying to solve?
> > 
> > Problem remains original.
> > 
> > "Automatic date update in version.in" commits are 
> >    - litter commits tree
> >    - create problems for deterministic, bit-identical and/or verifiable builds.
> 
> [snip distractions from the original problem]
> 
> > Am I quite clear?
> 
> No.
> 
> The "litter" problem is real, but minor.

Nice. Looks, that in first point we have consensus. :)

> 
> The determinism claim would have merit, if it were a real problem.

I think it's real. But it is another story, right?

> But it's not.  Every checkout of a given git hash gets the exact
> same sources with the same date stamp.  It's totally deterministic.

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.

> 
> So again, what problem are you trying to solve?
> 

Again, all stated above.

WBR,

--

  - ptr