[Rd] recent changes to r-devel with package date checking?

[Dirk Eddelbuettel]

Simon,

Just for closure, there were two not-fully-overlapping discussions going on.

1) Some breakage having to do with the time field, and you pointing at the
fact that Debian builds supply one.

As I was trying to provide in context, this is done _chiefly_ to ensure
repeated builds from the same source tarball are bitwise identical. And that
is achieved by replaced a read of 'current time' with a fixed string of
'recent time', taken for convenience from debian/changelog as it is both
guaranteed to be present (in the context where this came up: producing .deb
binaries for the Debiann (and derivatives) distro).

The key really is 'fixed string'. That the RFC 822 format is used is a)
because it is there, b) easily understood, c) even if less general than ISO
8601 and, importantly, accessible with a single call. The helper implementing
this these days is the 'buildsystem' provider for R used by debhelper,
implemented in the file [1] on Debian / Ubuntu. It has this one-line accessor
(on line 219 in my installed version)

   my $changelog_time = Dpkg::Changelog::Parse::changelog_parse()->{Date};

Again, as this is passed into to build and meant to be _fixed_ there is no
additional parsing or formatting.

2) You / R Core decide to use the Built: field inside of DESCRIPTION to sort
builds and depedendecies. With my Debian hat on, I slightly slant my head and
try hard to not say much more here. We are using a more extended scheme that
evolved over the years, and we seem to need all (added) components. The
entire discussion under 1) above was about making a resulting artifact, here
.deb files, be bitwise fixed and identical. R tries hard to do a lot a of
things with fewer resources. The DESCRIPTION file has source information in
the source tar.gz archive, but it also contains added fields created at
'install' or binary build time in the installed directory, or created binary
tarball. That can have challenges, but you know better and are well placed to
fight them.

Now, with 1) and 2), I think it does indeed become clear that in order to use
the timestamp passed in (as described in 1) above) for comparison, you
probably want to normalize it.  As Ivan very helpfully demonstrated, even
when there are binary 'non-maintainer builds' aka NMUs (ie builds made to
keep the archive consistent in build artifact without any source changes),
the appropriate buildstamp appears to be passed on as is. You would still
need to parse it to make it ISO 8601 (or alike) comparable.  Or ... maybe you
skip the step as the binaries you aim to produce are _not_ .deb binaries but
new-style CRAN binaries in a more naked compressed tar archive, and nobody
(as far as I know) is looking at reproducibility at the bit level as the
reproducible builds initative [2] that triggered the changes in 1) does.


Now, getting back to 1) above, it will not be affected if you make a change
to the timestamp passed in as long as the same changed string is passed
through. If the same transformation is done, we still have bitwise identical
builds satisfying the reproducibe builds initiative [2] that the Debian
builds aim at.

Makes sense?

Cheers, Dirk

[1] /usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm
[2] https://reproducible-builds.org/
-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org