This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: meaning of "Automatic date update in version.in" commits
On Thu, 21 Sep 2017 13:39:08 +0100
Pedro Alves <palves@redhat.com> wrote:
>
> On 09/21/2017 01:22 PM, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 12:36:46 +0100
> > Pedro Alves <palves@redhat.com> 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