[MacPorts] #63570: gdbm @1.21: destroot failure in some timezones (was: Failed to destroot gdbm: command execution failed)

[MacPorts]

#63570: gdbm @1.21: destroot failure in some timezones
----------------------+--------------------
  Reporter:  bryancn  |      Owner:  (none)
      Type:  defect   |     Status:  closed
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.7.1
Resolution:  fixed    |   Keywords:
      Port:  gdbm     |
----------------------+--------------------
Changes (by ryandesign):

 * keywords:  leopard powerpc =>
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In the attached main.log's build phase I see:

 {{{
 Making all in doc
 make[2]: Entering directory `/path/to/gdbm/work/gdbm-1.21/doc'
 Updating ./version.texi
 make[2]: Leaving directory `/path/to/gdbm/work/gdbm-1.21/doc'
 }}}

 Whereas on my High Sierra system I just see:

 {{{
 Making all in doc
 make[2]: Entering directory `/path/to/gdbm/work/gdbm-1.21/doc'
 make[2]: Leaving directory `/path/to/gdbm/work/gdbm-1.21/doc'
 }}}

 And then in the destroot phase of the attached main.log where we see all
 the `has no Up field` errors on mine I just see the installation of the
 pre-existing .info files.

 The `has no Up field` errors are apparently indicative of attempting to
 rebuild the documentation with a too-old version of makeinfo, which can be
 rectified by installing the texinfo port. However the real question is why
 the build system believes it should rebuild the documentation on your
 systems yet on mine it is happy to accept the documentation as included in
 the distribution.

 Looking in doc/Makefile.in, I see that it decides to update version.texi
 if its timestamp is older than the timestamps of gdbm.texi and the
 configure script. When the gdbm port was updated to 1.21, a patch for the
 configure script was added, meaning that its modification timestamp would
 be changed, meaning that it tries to update version.texi, only it doesn't
 update the file directly: it updates a temporary file called stamp-vti,
 and if that file's contents matches version.texi then it does not update
 version.texi, otherwise it copies stamp-vti to version.texi to update it.
 And based on the updated version.texi, it later in the destroot phase
 decides to rebuild the documentation.

 As distributed, version.texi contains:

 {{{
 @set UPDATED 2 September 2021
 @set UPDATED-MONTH September 2021
 @set EDITION 1.21
 @set VERSION 1.21
 }}}

 This date does not indicate a timezone. I am in CDT timezone whereas the
 main.log indicates NZDT timezone. If I change my system's timezone to NZDT
 then I am able to reproduce the issue, because then version.texi has been
 updated to:

 {{{
 @set UPDATED 3 September 2021
 @set UPDATED-MONTH September 2021
 @set EDITION 1.21
 @set VERSION 1.21
 }}}

 The problem was solved when gdbm was updated to 1.22 and the configure
 script patch was removed because it had been incorporated by the
 developers.

 We must remember in the future that if we patch the configure script, we
 should also touch version.texi so that documentation is not unnecessarily
 (and sometimes unsuccessfully) rebuilt. This probably applies not only to
 this port but to any port that builds documentation with texinfo.

-- 
Ticket URL: <https://trac.macports.org/ticket/63570#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS