V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > == Summary == > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > When an RPM package is built, mtimes of packaged files will be clamped > to `$SOURCE_DATE_EPOCH` Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If I had a source file dated 1970-01-01 and installed it with "install -p", will the packaged file retain that 1970-01-01 date, or will it be set to the date of the latest changlog, e.g. 2022-11-11? In other words, will all files in a package have the same mtime, or there won't be an mtime newer than the changelog entry? > which is already set to the date of the latest `%changelog` entry. What's a changelog entry date in case of rpmautospec changelog? Is it a git AuthorDate or CommitDate? > As a result, more RPM packages will be reproducible: Where will this reproducibility stop? An RPM package itself carry a build time in its RPM header. Are we also going to fake this time in the name of reproducibility? What value these faked timestamps have? E.g. a compiled file is a function not only of its source, but also of the compiler. This proposed change removes the compiler part from the timestamp. Will timestamps like this be helpful? Wouldn't be easier to admit that timesamps are nonsense and simply eradicate all of them stamps from various data formats rather than trying to fake them? Simply changing rpmbuild to set timestamp to 0 for all contained files, or removing the time attribute from the RPM format completely? -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
