| 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 |
| raboof | how is this breaking nixpkgs' -source patch convention? | 10:53:09 |
| raboof | * how is this breaking nixpkgs' -source path convention? | 10:53:19 |
| atemu12 | As trofi mentioned, it breaks the ability to construct the same source path from any source as long as it's the same content | 10:53:46 |
| atemu12 | Because in addition to the content you must have a matching epoch | 10:53:59 |
| raboof | I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant) irks me though, and "that's just the way it is in Nix" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:00:55 |
| raboof | * I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant) irks me though, and "that's just the way it is in nixpkgs" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:01:18 |
| raboof | * I see your point - 'same' is a tricky concept 😃. The widespread abuse of SOURCE_DATE_EPOCH in nixpkgs (setting it to a meaningless constant, technically achieving reproducibility at the cost of correctness/accuracy) irks me though, and "that's just the way it is in nixpkgs" is not a very satisfying answer if we want to claim to be forerunners in reproducibility ;) | 11:01:56 |
| atemu12 | raboof: I agree with you on that | 11:03:01 |
| atemu12 | It's just very difficult to do it differently on the technical side of things | 11:03:23 |
