Ability to create reproducable builds

[dralley]

We need to have the same knobs that rpmbuild has to enable reproducible package builds. Timestamps and various other things get in the way.

As far as I know the needed features are (equivalents to):

# Have SOURCE_DATE_EPOCH value set
%source_date_epoch_from_changelog 1
# Ensure no file timestamps are later than SOURCE_DATE_EPOCH
%clamp_mtime_to_source_date_epoch 1
# Force build timestamp to SOURCE_DATE_EPOCH
%use_source_date_epoch_as_buildtime 1
# Make the hostname deterministic
%_buildhost mockbuild

SOURCE_DATE_EPOCH is referring to https://reproducible-builds.org/docs/source-date-epoch/

[dralley]

SOURCE_DATE_EPOCH support is now implemented but in a slightly different way from rpmbuild. If the environment variable is set and parses correctly, we just use it, whereas rpmbuild has a separate flag for enabling it that you have to configure.

We don't currently have a way to clamp file mtimes, nor use the most recent changelog timestamp as the build timestamp. Maybe it makes sense to put all of this behind one "reproducable" option on RPMBuilder?

Open for discussion.

[drahnr]

I think the default should be to build reproducible rpms, the user then can opt in to provide i.e. the current timestamp or file timestamps or buildhost they desire. This would also enable the option to shed a few dependencies for i.e. the buildhost since the user would have to provide it, we don't need to have a dependency on the gethostname crate.

[dralley]

I'm told that in practice those fields are quite useful for debugging purposes, so it's actually useful to opt-in to reproducibility rather than the other way around. But I don't build RPMs myself frequently, so I can't validate that with personal experience.

[dralley]

However, I can presume that is with regards to rpmbuild. Programmatically generating RPMs is slightly different.

[dralley]

If you want to take this issue and 5cfc3be#diff-b82882f602be2cf2d09fd6546c2097235d9417da83223e9516b8eb783c6257ffR233 and work on it, then that is fine with me.

[dralley]

@drahnr How do you think

# Ensure no file timestamps are later than SOURCE_DATE_EPOCH
%clamp_mtime_to_source_date_epoch 1

ought to be handled, if at all. Basically you could rewrite the same bit-identical file (if this were part of some build pipeline) which would still end up changing the resulting package. The mtime is derived from the file on our end, so it's not possible to work around.

[dralley]

I'm going to close this on the basis of reproducible builds being possible (the title is satisfied), although we should continue to improve the ergonomics.