| 20 Sep 2023 |
 atemu12 | * A thing that occured to me, what are we actually trying to fix by doing that? | 10:42:52 |
 raboof | by restricting multiple outputs in FODs? | 10:43:22 |
| atemu12 | No, getting the date from the tarball | 10:43:33 |
| atemu12 | Because in order to achieve reproducibility, we only need to set SOURCE_DATE_EPOCH=1 | 10:44:09 |
| raboof | ah - well, the meaning of SOURCE_DATE_EPOCH is the date of the last modification of (typically) the source code, which applications then can use for thing like showing "Welcome to Foo version X, 2023-09-20". Indeed setting it to 1 is just as reproducible, but less user-friendly (showing weird 1970 dates instead of 'meaningful' ones) and arguably somewhat abusing the concept. | 10:48:19 |
| atemu12 | Ah, so the point of this is a cosmetic improvement but retaining existing r13y | 10:50:20 |
| raboof | yes | 10:50:42 |
| atemu12 | I think in that case the better approach might really be just adding a mkDerivation arg with the epoch for those few% of packages where it'd matter | 10:50:57 |
| atemu12 | I like the idea of having the actual timestamp globally but breaking Nixpkgs' -source path convention is quite a steep hill and will probably even net you a veto from out BDFL ;) | 10:52:27 |
| atemu12 | * I like the idea of having the actual timestamp globally but breaking Nixpkgs' -source path convention is quite a steep hill and will probably even net you a veto from our BDFL ;) | 10:52:31 |
