Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

[Daniel Shahaf]

Bruno Haible wrote on Sat, 15 Jul 2017 21:24 +0200:
> Daniel Shahaf wrote:
> > So: should po file generation allow the caller to control the timestamp
> > that would be embedded?
> 
> No, that would be a regression for the translators.
> 

No, it would not.  The proposed change is to set the timestamp header to
a caller-provided value.  Translators would not be providing a value,
and therefore would not exercise the codepath being proposed for
addition and would experience no change in behaviour.

> > > it's plain text, and it's a small diff.
> > 
> > This doesn't scale.  (For example, in my use-case, I'm dealing with a
> > 5000-line unified diff full of one-line changes in date strings and C
> > comments and any number of other things. My goal is to get the number of
> > lines down to zero.)
> 
> Then you will have to filter out the one-line changes that are not
> important to you.
> 

As I said, this doesn't scale.  I have multiple upstreams to filter in
this way; I assume others are in my position too; and the filter would
be a moving part in itself.

To put it differently: if I have to use diffoscope to see that two
things are equivalent, I've already lost.  There is a world of
difference between things that are equal according to cmp(1) and things
that are equal according to diffoscope(1): the latter notion of
equivalence is much weaker in practice.  (E.g., it doesn't allow for
content addressing, it makes audits harder, etc.)

> The purpose of tarballs is distribution to developers, translators,
> and distros.
> 
> The purpose of Makefile.in.in rules that generate .pot files is:
> The .pot files are the starting point for translators (or for the
> Translation Project, which extracts the .pot files and makes them
> easily accessible to the translators).
> The date of the POT file is important info for the translators.
> 

The date would remain available to translators: whoever generates the
tarball for distribution to translators not be using the new codepath.

> This is the main workflow. It allows for reproducible builds (through
> the timestamp filtering now built into msgfmt).
> 
> > I am asserting that there is another workflow which would be simpler if
> > .po file headers were also reproducible.
> 
> You'll have to adapt. Accept the main workflow as it is.

You'll have to adapt.  Keep the main workflow unperturbed but add a
modified workflow to cater for different use-cases.

tl;dr: The proposed change is 100% backwards compatible.

Daniel
(I'll slow down my replies for a bit to give others a chance to chime in.)