Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus"): > Instead, file conflicts might be created from files with > content that depends on SOURCE_DATE_EPOCH.
tl;dr: Analysis. Revised proposal: Introduce BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) and use it for file timestamps (only (for now)) We have a difficulty now. There are, for a MA-Same package, two relevant timestamps: (i) The time of the original source package changelog. I'm going to call this the `source timestamp'. This has to be used for the embedded timestamps of all shared files in MA-same packages. Note that it is technically not correct to use the source timestamp for embedded timestamps of these files. Consider a package which is binnmu'd on all architectures because a documentation rebuild is needed. In practice, though, such timestamps are generally either in hidden places and ignored by almost anything, or displayed to users in a kind of context where users are already often exposed to out-of-date timestamps (or where users might already expect the timestamp to relate to the content of the documentation, rather than the time it was last reformatted). It would be tolerable although technically not quite correct, for the reasons I have just discussed, to use the source timestamp for embedded timestamps of arch-specific files in MA-Same packages, and embedded timestamps of all files in non-MA packages. (ii) The time of the binnmu build (or perhaps the time, when the binnmu request was generated and the request message chosen etc.) I will call this the `binnmu timestamp'. This should be used (at least) for all file timestamps of any arch-specific files (to avoid the bug I reported at the start of this thread). This timestamp can safely be used for _file timestamps_ of all files, without disturbing reproducibility. It would be correct to use this timestamp for embedded timestamps in arch-specific files, since (in the usual case), arch-specific files will change on such a rebuild. There is no reason not to use the binnmu timestamp in these cases, except for the effort of causing this to happen. It would be correct to use this timestamp for embedded timestamps in MA-same shared files iff the shared files were (intentionally) changed by the rebuild. We don't have a mechanism to say, right now, whether that is the case. I don't think it is possible to make the binnmu timestamp the same across architectures. For example, a package might be rebuilt only on some architectures. I don't think we want to change that. In particular, even if we were prepared to change that in Debian, we should not impose always-binnmu-all-arches as a rule on all our downstreams. Both of these timestamps are in principle available to dpkg, dh, et al. I suggest the following scheme: * The binnmu timestamp will be set to the current time when the binnmu changelog entry is generated. (The whole binnmu changelog entry must in any case be reused when a build is to be reproduced, so there is no reproducibility hazard here.) * For file timestamps of generated files, we will use the binnmu timestamp. * For all embedded timestamps in shared files, we will use the source timestamp. * For embedded timestamps, we will initially use the source timestamp; but, we will treat the misleading timestamp as a minor bug and intend, eventually (ie some time next century) arrange for it to be set to the binnmu timestamp, where possible. We would implement this as follows: 1. dpkg-buildpackage will be changed to set BUILD_DATE_EPOCH to the binnmu timestamp, if there is one. It will set it to the source timestamp otherwise. dpkg-buildpackage will conversely be changed to set SOURCE_DATE_EPOCH to the _source_ changelog timestamp, even if there is also a binnmu changelog entry. 2. dpkg-deb will be changed to honour BUILD_DATE_EPOCH instead of SOURCE_DATE_EPOCH, if it is set, when clamping file timestamps. 3. sbuild should be changed to set the binnmu changelog timestamp to the answer from time(2), by default. 4. Eventually, if anyone cares, we will teach tools that generate arch-specific files, and include timestamps, to honour BUILD_DATE_EPOCH (either by adjusting those tools directly, or by adjusting the way they are called by dh, or whatever). We could also arrange for SOURCE_DATE_EPOCH to be set to the binnmu timestamp iff the package generates no MA-same .debs, or other crazy things. None of these future changes are essential for our tools to function correct; they only fix the minor cosmetic issue of misleading embedded timestamps. Ian. ;4~ -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.