Re: [PROPOSAL] time zones and reproducible builds (was: How to make groff use local timezone?)

[Deri]

On Tuesday, 22 December 2020 03:41:14 GMT G. Branden Robinson wrote:
> > I may be misunderstanding something here, apologies if I am.
> 
> No, I appreciate you speaking up--I welcome critical evaluation of my
> suggestions, especially in cases like this where I haven't carved out
> enough time to experiment and research an issue as much as is my usual
> preference.
> 


Again, I fear I may be missing something obvious. My background is in the arts 
not computer 
science, I wanted to be an archivist when I grew up but I realised that 
dribbling on the Magna 
Carta or an inability to put on latex gloves may have been a hindrance to my 
career!

Please can someone explain why reproducible builds are important. I assumed 
that it was to 
detect when the output produced from a system has changed. The purpose is to 
detect changes 
in the system which may have unintentionally been altered by changes to the 
system.

This means that we are not interested in changes to the source code, but purely 
if any changes 
have occurred in the output when the system is run. After all a change to the 
source code may be 
intended to improve performance but unintentionally alters the output.

What is the output of groff we should be testing. It looks like we are 
comparing the files that 
groff's output processors produce, but this does not make sense to me. Grops 
outputs the source 
code of a new program. Gropdf outputs a file in the PDF language. Since these 
are essentially 
source files which are intended to be run at some point, diffing them just 
tells us that there has 
been a change in grops or gropdf, not whether that output, when run, has 
changed.

Isn't the actual build output of groff marks on the page, and it is this we 
should be comparing to 
detect changes between one version and another, not the source code produced by 
groff which 
needs to run in order to produce the marks. I'm sure if the postscript or pdf 
is rastered to a binary 
bitmap and new and old are subtracted from each other, if there are any black 
pixels left in the 
image then it has failed the reproducibility test. If the result is a 
completely white page there has 
been no difference between the two builds, even if the post processor has had 
changes which are 
intended to improve the file it produces, but those changes have not altered 
the result of 
"running" that file.

I can't see the purpose of diffing the source code files which the post 
processors produce, since 
they tell you nothing except the code in the post processor has changed, not 
whether the new 
code has altered the marks on the page when they are run to produce their 
output.

Am I missing a nuance that makes diffing the source code produced by the post 
processors 
useful?

Cheers 

Deri