Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus
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 <ijackson@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.
Reply to: