[rb-general] Clarification re SOURCE_BUILD_EPOCH and clamping

Ximin Luo infinity0 at debian.org
Thu Oct 19 11:12:00 CEST 2017


Chris Lamb:
> Hey,
> 
>> 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.
> 
> As in, overiding the SOURCE_DATE_EPOCH already set by, for example,
> dpkg...?
> 

Right. This was a long-term intention from day 1 of the idea TBH.

Overwriting with a later date is allowed, because you might the case where: package A depends on an external package B installed elsewhere in the system, your build process needs to include material from package A and B, B was upgraded to a version later than the SOURCE_DATE_EPOCH of A, and B doesn't want to be compiled with an older date (as that would be surprising). In that case the subprocess building B should be able to read a newer date from B's own files.

>> I think the "too complex" argument carries weight for random esoteric
>> stuff or too-lengthy explanations, but neither of the changes here are
>> that
> 
> Oh that's totally fair, I'm just ensuring that the "is this definitely
> being used, or are we just being pedantic" boxes are being ticked.  :)
> 
>>> Where build processes embed timestamps that are not "current",
>>> but are nevertheless still specific to one execution of the
>>> build process […]
> 
> Despite what I've been saying, I wonder if this bit would be improved
> with *some* kind of very terse eg.-based example, otherwise it reads
> a little too abstract.
> 

That makes sense, dkg had some examples in another branch and I'll go pull it or parts of it in.

X


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


More information about the rb-general mailing list