[PATCH 3/9] sb: Do not report current date

Chris Johns chrisj at rtems.org
Mon Dec 8 21:42:58 UTC 2014


On 9/12/2014 8:07 am, Gedare Bloom wrote:
> On Mon, Dec 8, 2014 at 3:52 PM, Chris Johns <chrisj at rtems.org> wrote:
>> On 8/12/2014 5:48 pm, Sebastian Huber wrote:
>>>
>>> This makes the report reproducible.
>>
>>
>> I think the report should include a date. I do not see any advantage having
>> reproducible reports. The report captures the specific instance of the
>> build.
>>
> Would it make sense to re-build on a different date and want to
> compare the results to see there is no difference?

What you build on a different date cannot be the same by definition. 
The date has changed. In a quality context if you reference the first 
build that is what you have. You cannot reference an initial build and 
then say you used a subsequent build because you know it is the same. 
Where is the dated report to say they are same ? The report is about 
reporting what you did and what happened.

> Maybe a flag can be turned on/off for "reproducible" builds.

I do not like flags being available for things like this. The user then 
needs to audit the setting and this moves the compliance back up to the 
user.

> Or is it the user's
> responsibility to strip out such non-reproducible bits if they want
> such a feature?

I can understand an MD5 hash on the components built and that result 
being in a report. I have never tried to see if a repeat build of the 
tools produces an exact binary image.

I can also understand a user explicitly adding an exemption to an audit 
process not to check the report. For example it is common to see target 
binary images have exemptions for date and time strings embedded in them 
and a manual audit with a hex dump to verify this is the only difference.

Chris



More information about the devel mailing list