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

[Dmitry Samersoff <dms@samersoff.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

On 20.09.2017 18:39, Matthias Klose wrote:
> On 20.09.2017 17:05, Joel Brobecker wrote:
>> [adding the GDB group, as this affects both]
>>
>>> What is the meaning of "Automatic date update in version.in" commits?
>>> I mean commits like f625a739e5.
>>>
>>> This commits litter commits tree and create problems for  	
>>> deterministic, bit-identical and/or verifiable builds.
>>>
>>> May be worth to remove this (historical?) artifact?
>>
>> We've had that discussion several times in the past. I'd be quite
>> happy to get rid of that daily commit, and most people here probably
>> would be too. The issue is that no one has been able to get us
>> to agree on what we should be doing instead, and then implement it.
>> Part of the obstacles, I think, is that everyone has their own idea
>> of the requirements that should be met. Maybe one solution would be
>> to ask the group of Global Maintainers to make a decision (at least
>> for GDB) once everyone had a chance to provide their feedback. Once
>> we have a clear plan of what should be done, I suspect finding
>> a volunteer to implement it wouldn't be too hard. I might even
>> take an hour or two in a weekend to look into that...
> 
> For binutils the date gets encoded into the libbfd and libopcodes soname, so you
> are pretty safe during development.  Maybe you could manually bump the version
> when it is needed, but I assume that is more difficult than the automated daily
> bump.

If it's the only purpose of daily commit, than the obvious solution is
to improve daily commit script and update version.in only if source code
changes.

My $.2
-Dmitry



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]