Reproducible builds

[newpavlov]

Right now by default generate-rpm crates non-reproducible RPMs. It can be worked around by using --payload-compress none and manually setting modification time of included artifacts right before RPM generation. Ideally, it should be handled by a simple flag.

Also I don't quite understand why enabling compression makes builds non-reproducible.

Relevant issue: rpm-rs/rpm#117

[cat-in-136]

I am against "it should be handled by a simple flag" but reproducability of rpm file is acceptable.

As you know it is depending on timestamp and other time-related conditions. I believe that these parameter should be manually set by the user who wanna get reproducable builds.

Of cause currently compression issue and some missing fields needed to be added to the purpose. Simply speaking, it is just depending on rpm-rs/rpm#117.

[newpavlov]

I think a SOURCE_DATE_EPOCH-like flag should be sufficient for time-related conditions. As a convenience it would be nice to have additional flags which set it to the beginning of the UNIX epoch and to date of last commit in current repository.

[cat-in-136]

Again, simply speaking, this issue is just depending on rpm-rs/rpm#117 and need to clarify on requirements on rpm-rs/rpm. It is impossible to clarify single flag is suitable or not.

BTW, the original rpmbuild have such a "simple flag"?

[newpavlov]

this issue is just depending on rpm-rs/rpm#117 and need to clarify on requirements on rpm-rs/rpm.

Yes, I understand. This is why I linked the issue. I created this issue to make it easier to find for users of generate-rpm who are interested in reproducibility and to discuss potential shape of CLI API.

BTW, the original rpmbuild have such a "simple flag"?

IIUC it's done by setting %source_date_epoch_from_changelog, but I haven't used it myself.

[cat-in-136]

So, the feasibility of a fully working simple flag is not clear. Such a simple flag need to be careful about because users expect complete behavior.

I will leave this ticket open. Please create other tickets or PRs to introduce each respective settings (mtime, build time, etc.).