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

[Petr Ovtchenkov <ptr at void-ptr dot info>]

On Thu, 21 Sep 2017 12:36:46 +0100
Pedro Alves <palves@redhat.com> wrote:

> On 09/21/2017 11:58 AM, Petr Ovtchenkov wrote:
> 
> > Date is worst thing that you may use in SONAME. Especially in conjunction
> > with attempts to use DVCS as date source. (D == _Distributed_, so _no
> > time ordering_). And I should repeat:
> > 
> >   - from datestamps equality not follow ABI compatibility,
> >   - from datestamps inequality not follow ABI incompatibility.
> > 
> > What you want achieve with SONAME variations?
> 
> What do _you_ want to achieve with removing the date stamps?
> 
> You started the thread with:
> 
> > This commits (...) create problems for  	
> > deterministic, bit-identical and/or verifiable builds.
> 
> ... which is false.  The rest of the thread seems like trying
> to change the goal post in order to justify change so that as side
> effect we'd fix the problem with determinism that you
> claimed exists, but that doesn't actually exist.
> 
> 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.

As I see, discussion shifted to "how to add date stamp in SONAME".
But this "solution" will not resolve originally stated problem:
all variants that I see prevents "deterministic, bit-identical and/or verifiable builds",
and some keep "garbage in commits tree". All suggestions trying to use date stamps---nonsense
from technical point of view.

Difference in SONAME should reflect difference in ABI. Right?
I.e. libs with same SONAME have to have compatible ABI, while
libs with different SONAME may have incompatible ABI.

Date stamp as addition to SONAME can't satisfy to this requiremens. The samples was above.

Am I quite clear?

--

   - ptr