On 2025-05-07, Simon Josefsson wrote: > My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the > timestamp inside a man page. This is just one of many symptoms that > will arise from trying to use SOURCE_DATE_EPOCH in an upstream context. > > It seems generally better if upstream derive timestamps inside artifacts > from the source code for that artifact, or the last upstream release if > tracking the source code is problematic. Then these timestamps will be > stable during all future rebuilds of the same artifact.
The source code for debian packages includes debian/changelog and other files in debian/ ... which could include patches to the manpages or otherwise affect the downstream artifacts... so the upstream timestamps could potentially be misleading in some cases. > In this case, is the problem triggered by this line? > > https://salsa.debian.org/debian/autogen/-/blob/8b4268fa779deaba862a7938ee0d5f051860d8e7/debian/rules#L11 That code appears to work as intended, though there appear to be some problematic interactions with multi-arch:same packages and binNMUs which may have differing debian/changelog entries for the "same" binNMU version across all architectures... > If so, the problem is not in upstream but in the packaging. A more > relevant timestamp to use appears to be the last upstream release > timestamp, or the timestamp from debian/changelog (sdate, not bdate). > Using SOURCE_DATE_EPOCH here seems just wrong on a conceptual level. When building Debian packages, SOURCE_DATE_EPOCH is typically set from debian/changelog... so I am not sure why you are objecting to SOURCE_DATE_EPOCH here if setting the timestamp from debian/changelog seems ok to you. The whole point of SOURCE_DATE_EPOCH is to set a value that upstream code and tools used in build systems (e.g. dpkg-buildpackage, debian/rules, gcc, etc.) can consume to use a consistent timestamp, without having to get into the specifics or internals of each individual build system; each build tool or build system can consume SOURCE_DATE_EPOCH and produce appropriate time related data in whatever way is appropriate for that tool or build system. Though of course, timestamps are best avoided, and SOURCE_DATE_EPOCH is best used as an option for when there is no way to avoid a timestamp. live well, vagrant
signature.asc
Description: PGP signature
