| 20 Sep 2023 |
 atemu12 | raboof: Just did a quick PoC aaaand error: multiple outputs are not supported in fixed-output derivations | 10:41:19 |
| atemu12 | How did you get far enough to worry about reading them? | 10:41:33 |
 raboof | I started with the part that seemed most problematic to me (thinking of ways how to consume the data, assuming it was there) | 10:42:15 |
| atemu12 | I see | 10:42:34 |
| atemu12 | A thing that occured to me, what are we actually trying to fix by doing tht? | 10:42:49 |
| 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 |
| atemu12 | Without losing other technical properties | 11:03:34 |
| atemu12 | We'd either need to break the implicit source convention or do something like having two hashes (one for content FOD, one for timestamp FOD). Neither of those are desirable from the technical side I think and the latter would be better served by setting the epoch manually as I mentioned | 11:05:39 |
| raboof | it's a balance, I'm not convinced yet the convention is 'broken' in such a meaningful way here - it's already true that fetching a tarball is slightly different from fetching the same sources from git, for example. The fetchers already have parameters to modify their behavior, so adding a 'keepSourceDate' parameter seems consistent with that (and nicer than having to manually update such a 'epoch' field every time you update the src). I guess whether to enable it by default could be more contentious ;) | 11:11:15 |
| atemu12 | raboof: The thing is that you could fetchzip the tarball or zip file on github, fetchgit from any git host in existance or copy the source tree off a USB drive and always arrive at the same store path | 11:13:37 |
| atemu12 | There are optional flags to sprinkle in additional information but never by default | 11:14:46 |
| atemu12 | * There are optional flags in different fetchers to sprinkle in additional fetcher domain-specific information but never by default | 11:15:11 |
