replacing rpm its %source_date_epoch_from_changelog . This instead also
increments the date by the build counter, which OBS puts into the
release field of rpm. When available it uses the mtime that OBS its
scmsync obtains from the git HEAD commit date instead of from the
changelog.
All this can be disabled by setting the rpm macro
%disable_obs_set_source_date_epoch to Y .
This uses new variables in /.buildenv that were implemented in
openSUSE/obs-build@5d1da85
.
See https://reproducible-builds.org/docs/source-date-epoch/ for general
introduction.
Increasing the date by the build counter is necessary, so that that even
for rebuilds with unchanged source but updated build depends the date is
always increased, such that no build with a different input/output has
the same date.
Not increasing the date breaks rsync without --checksum or anything else
that relies on modification time stamps of files to detect changes.
That the build counter is the number after the first dot of the release
is a OBS convention. This breaks if a Release is set manually in the
spec file.
When %clamp_mtime_to_source_date_epoch and
%source_date_epoch_from_changelog are enabled and a rebuild is done with
different build dependencies a file may have different content but with
the same mtime. When two releases of this rpm are extracted after each
other at the same location and the extracted files are synced with rsync
without --checksum, then the resulting copy will contain a mix of files
from the old and new build. This can happen on installed systems due to
updates when it is then backed up with rsync. While it is not safe
generally safe to rely on mtimes and thus nor to backup systems without
--checksum, we should not unnecessarily break things. We came across
this problem because this happens for rpm repos from OpenSUSE that have
extracted files used for installing from a repo, which get broken when
mirroring with rsync, see
https://bugzilla.suse.com/show_bug.cgi?id=1148824 .