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

[Simon Urbanek]

Dirk,

can you clarify one thing for me? In principe, if I read the Debian specs correctly[1] using the changelog date creates an entry that is semantically incorrect for this field since it is the *source* change time, so does not reflect any re-builds, but whether that matters for our purpose depends. So the question is: if a package needs to be re-built (=new binary needs to be created) due to either another package's ABI change (classic example was Matrix, but there are other S4 cases), does that trigger in Debian a new source release with updated changelog even if the actual sources for the package don't change?

Thanks,
Simon

[1] - https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog


> On 27 Mar 2026, at 09:29, Dirk Eddelbuettel <edd using debian.org> wrote:
> 
> 
> Hi Simon,
> 
> On 27 March 2026 at 08:56, Simon Urbanek wrote:
> | FWIW the date comparison have been in place for a while and is unrelated to the recent changes, but, yes, it's easy enough to a) treat unrecognized timestamps as simply "old" and possibly b) add support for the Debian timestamps so I'll look into that.
> 
> Appreciate that.
> 
> If you look at 'svn blame' you will see that we put this in place many moons
> ago.  And if I look at my Debian buildlog, e.g. from Rserve two days ago, we
> see use of the '--built-timestamp' field for this very propagation.
> 
>    [...]
>    make[1]: Entering directory '/build/rserve-1.8-19'
>    dh_auto_install
>    I: R Package: Rserve Version: 1.8-19
>    I: Building using R version 4.5.3-1
>    I: R API version: r-api-4.0
>    I: Using built-time from d/changelog: Tue, 24 Mar 2026 05:38:00 -0500
>     mkdir -p /build/rserve-1.8-19/debian/r-cran-rserve/usr/lib/R/site-library
>     R CMD INSTALL -l /build/rserve-1.8-19/debian/r-cran-rserve/usr/lib/R/site-library --clean . --built-timestamp="'Tue, 24 Mar 2026 05:38:00 -0500'"
>    * installing *source* package 'Rserve' ...
>    ** this is package 'Rserve' version '1.8-19'
>    [...]
> 
> Here dh_auto_install is just a (distribution-wide) convenience wrapper from a
> system called debhelper, all this is (these days) standardized so much that
> there is a common caller for R package that sets this up. It is in a package
> dh-r with the R specific bits that plug into debhelper (it's all pretty old
> code by others, mostly in (horror) Perl, what is used now is in a file R/pm
> inside the dh-r package) but there is also the old hook 'r-cran.mk' we used
> to call directly that has the (no longer called, but replicated functionally
> in R.pm) bit with a comment and code:
> 
>    ## Bug report #782764 with patch by Philipp Rinn building on what we had above
>    ## if no builttimeStamp is supplied, set built-time (to be set in DESCRIPTION).
>    ## to time of created source package based on stamp in changelog..
>    ## See discussion in http://bugs.debian.org/774031
> 
>    ifeq ($(builttimeStamp),)
>      builttime       := $(shell dpkg-parsechangelog -l$(CURDIR)/debian/changelog | awk -F': ' '/Date/ {print $$2}')
>      builttimeStamp  := "--built-timestamp=\"$(builttime)\""
>    endif
> 
> and that links to https://bugs.debian.org/782764 from 2015 (!!) which has more.
> 
> So in short we should for this be picking up our own (unchanged) timestamp
> from our changelog; it may be that when the option is not set a different
> format propagates and now creates a 'surprise'.
> 
> Cheers, Dirk
> 
> -- 
> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>