[bug #59658] xgettext and msginit don't honor SOURCE_DATE_EPOCH

[Bruno Haible]

Follow-up Comment #6, bug #59658 (project gettext):

We need to separate the issues.

1) What the "reproducible builds" initiative is about: See
https://reproducible-builds.org/docs/definition/ .

The "artifacts" defined there is what gets installed through "make install"
and packaged as an installable package (rpm, deb, whatever) by the distro.
This includes the *.gmo files; it does not include a POT file nor any *.po
files.

The "source code" defined there is a tarball, because GNU provides its
software through releases and tarballs, and for the vast majority of packages,
this is what the distros take as their inputs.

In this area, the en@quot.gmo and en@boldquot.gmo files are an issue, and the
solution I propose is that 'msginit --no-translator' omits the
PO-Revision-Date from the output.

2) "As a software developer I'd like to be sure that anybody can reproduce the
distributed tarball from the sources used to generate it"

I guess you mean "as a software developer of a package that uses GNU gettext
for its po/ directory". (Because for GNU gettext itself, the tarballs are
authenticated through the signature of the file on ftp.gnu.org, and thus there
is no need to create another tarball for comparison.)

The "sources" in this case are a version control repository (most likely).

In the current state of things, with issue 1) fixed, two tarballs produced by
different people will contain identical files, except for POT-Creation-Date
values in the *.pot and *.po files. No differences in the *.gmo files. Someone
who compares such different tarballs can do so with a textual compare ("diff
-r"). No need for special tools like 'diffeoscope'.

To me, that is good enough.

Do we want to have it differently by default? No. The POT-Creation-Date values
in the *.pot and *.po files are important for the translator workflow.

Do we want the possibility for tarball builders to force a "POT-Creation-Date:
1970-01-01 00:00:00" in all *.pot and *.po files? No. If such a tarball gets
in the hands of a translator, her workflow is negatively impacted.

Should the POT-Creation-Date be replaced by something else that is not a date?
Since non-linear versioning control systems are in  use (e.g. git with
branches), people are sometimes using a 'git describe' output for the version
number. But for a translator, a version number "3.4-rc1" definitely makes more
sense than "3.4-217-ce814b" or - even worse - just "ce814b".

Should the POT-Creation-Date be replaced by a date that is not the current
date but instead reflects the latest modification to the version control
history? I am open to such a thing. It could be enabled by the package
maintainer in the 'Makevars' file.
The code to produce the date could be something like:

git_checkout_date=`git log -n 1 --date=iso --format=fuller | sed -n -e
's/^CommitDate: //p'`
pretty_date=`LC_ALL=C date +"%e %B %Y" --date="$git_checkout_date"`



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59658>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/