`SOURCE_DATE_EPOCH` (see
https://reproducible-builds.org/docs/source-date-epoch/ ) should be increased
every time the build output changes. Rebuilds with different build dependencies
do not necessarily have a new changelog entry. To ensure that it increases
increment the `SOURCE_DATE_EPOCH` by the release number.
The reason for it is that when it does not increase there may be complications.
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 that are
backed up with rsync. While it is not safe to backup systems without
`--checksum`, we should not unnecessarily break things. But 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 .
https://github.com/rpm-software-management/rpm/blob/59bbb932e5a546152a28cea9036958c324669b82/build/build.c#L329
However the release is a string with multiple version components, so it could
be much bigger than a unix time stamp. E.g. in Fedora `3.fc40` is common. And
there are packages that are not touched for years. So even only including the
40 would reduce the available numbers for rebuilds too much, e.g. for 3*40,
then one day of `SOURCE_DATE_EPOCH` only leaves space for a release up to
2160.fc40 ( =60*60*24/40 ).
So, my current idea is to only extract a number at the start of the string (3
in the above example). Then add that to the date of the changelog.
(And if one wants to make sure this doesn't fail then one needs to run a CI job
that checks that the different resulting dates of all builds don't overlap.)
Any better ideas?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2676
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
