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

[Dirk Eddelbuettel]

Hi Simon,

On 27 March 2026 at 09:57, Simon Urbanek wrote:
| 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.  

Let's step back for a second as I think you are reading something into the
'builttime' stamp that is not there. 

Recall that *everything* in Debian works off *package versions* and their
sorting. Always has. Likely always will be. CRAN copied that. 1.2-3 is older
than 1.2-4.

The timestamp never entered, and never will. The timestamp, as per my earlier
email in the thread, ensures that two binary builds are identical _because we
impose an 'available recent time'_ (of when the maintainer last updated the
package) simply because it shadows the package version sorting.  But again,
the whole point of the (fixed) timestamp is to reduce (arbitrary) variation
in the build artifact even when sources and build systems are fixed (and
variation is caused from reflecting current time in the build, a source of
variation).

We can look at an example. As I tend to be on Ubuntu (which does more
rebuilds for syncs anyway) I just glanced into the rocker/r-base container
(aka r-base). And a few packages in we have 'bzip_1.0.8-6+b1' -- the sixth
Debian variant of upstream 1.0.8, and here in '+b1' rebuilt because
_something_ in the toolchain required it. That is triggered and executed by
_the archive maintainers_ as opposed to the package maintainer -- and as a
purely binary rebuild _it has no changelog entry_ and hence no timestamp to
reason.

Everything sorts by _version_.

| 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

It is guaranteed to get a new _version number_. There is an entire
(elaborate) system of suffixes, usually '+b1' (for first binary rebuild)
for unchanged sources. Changes source, of course, get a new versison.

| 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?

Again, a valid question, but one 100% unrelated to 'builttimeStamp'. I am
happy to go over how r-cran-matrix was or was not rebuilt. In that example, I
think we may have forced new source minors (repeatedly) but it has been a
while. And given the above, as these would be _maintainer_ rebuilds not
archive rebuilds a new version number, or just a Debian minor, makes sense.

Let me know if I misunderstood something but it seems to me that you were
inferring issues simply not present here. Hope the explanation makes sense.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org