[rb-general] Clarification re SOURCE_BUILD_EPOCH and clamping
infinity0 at debian.org
Wed Oct 18 20:25:00 CEST 2017
> Hi Ximin,
>> They MAY overwrite it with a higher (more recent) value.
> How come, out of interest? Do we have any real-world examples of
> people screwing up implementations because we haven't specced it out?
> If not, I strongly believe there is a trade-off here between adoption
> and complexity (or even sheer length) of the specification. Capturing
> and documenting every corner-case is thus not necessarily in our best
> overall interests when you take a step back.
It's to allow upstream tools to experiment with setting SOURCE_DATE_EPOCH themselves, e.g. from git or something, and doing this in a way that doesn't result in surprises. It's similar to how you can append stuff to BUILD_PATH_PREFIX_MAP, but you can't delete stuff from it.
Also it's not a "corner case" but half of all cases.
>> Where build processes embed timestamps that are not "current",
>> but are nevertheless still specific to one execution of the
>> build process […]
> I remain unconvinced that clamping should be part of the spec; again,
> is it something that upstreams are finding problematic that it needs
> fleshing out…?
It's been used in practice and many of us including me personally recommend it for certain significant use-cases. The spec currently misses that part out. This would give us greater weight in recommending this to upstream authors that might otherwise make noises about "it's not part of the spec".
I think the "too complex" argument carries weight for random esoteric stuff or too-lengthy explanations, but neither of the changes here are that. I haven't seen anyone in practice argue against implementing the spec because it was getting close to being too complex. OTOH I have seen people make arguments against doing clamping (and the resulting build remains unreproducible) because clamping wasn't mentioned in the spec (e.g. __TIMESTAMP__ for C programs).
More information about the rb-general