[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: