[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