| 17 Mar 2024 |
 Robert Hensing (roberth) | For it to go missing would be bad | 13:51:08 |
 infinisil | Both behaviours could be useful | 13:51:30 |
| infinisil | Though I guess it's rare that you'd be okay with not getting a match, or a different match, if there's a build failure | 13:52:13 |
| infinisil | So fair | 13:52:18 |
| Robert Hensing (roberth) | It could be updated through the channel update process, but the data should be available on non-channel branches | 13:52:30 |
| Robert Hensing (roberth) | I mean the hydra-based channel update process, not nix-channel | 13:54:23 |
| infinisil | I don't see how that could work. Somebody needs to do the processing, and it won't work for every commit | 13:54:25 |
| infinisil | Yeah how channels work isn't ideal, but the basic idea of having more slowly updating references that are tested is a good idea, and can't be replaced with git branches | 13:56:04 |
| infinisil | * Yeah how channels work isn't ideal, but the basic idea of having more slowly updating references that are tested is a good idea, and can't be replaced with git branches only | 13:56:09 |
| Robert Hensing (roberth) | I think this solution is worth considering because it's close to how programs.sqlite was traditionally created for the non-git channel tarballs. I'm pretty sure it needs a hydra evaluation, so it may make sense to make it part of that process instead of a separate cron job. | 14:00:26 |
| Robert Hensing (roberth) | Basically it changes where the data is written to, instead of changing the whole process | 14:00:48 |
| Robert Hensing (roberth) | I've never seen the channel script though - I've only heard about what it does, so grain of salt. | 14:01:21 |
| infinisil | Oh I see what you mean, so instead of putting programs.sqlite in the channel release, it's committed to the source directly | 14:01:47 |
| Robert Hensing (roberth) | Yeah | 14:01:59 |
| Robert Hensing (roberth) | I don't think that script is in Nixpkgs, or is it? | 14:02:08 |
| Robert Hensing (roberth) | * I don't think that script is in nixpkgs, or is it? | 14:02:21 |
| infinisil | Robert Hensing (roberth): https://github.com/NixOS/nixos-channel-scripts | 14:02:35 |
| infinisil | Pretty sure | 14:02:40 |
| infinisil | Can't say I'm a fan of the idea, or at least it won't quite work as is. If you run Hydra for commit X, it calculates programs.sqlite for it, but now you need to push it with commit X+1. If you publish commit X as the channel update, people won't get the latest programs.sqlite. | 14:05:14 |
 K900 | Indeed | 14:05:02 |
| K900 | Putting it into nixpkgs is a bad idea | 14:05:23 |
| K900 | Unless we add LFS | 14:05:32 |
| infinisil | Could be fixed by publishing X+1 instead, which probably requires extra permission to do a direct git push to master | 14:05:46 |
| K900 | But adding LFS is also a bad idea | 14:05:38 |
| infinisil | Ultimately it just feels like git commits is not the tool for this due to their immutability | 14:06:33 |
| infinisil | I guess you could use git notes, which can be attached to commits after the fact | 14:06:58 |
| Robert Hensing (roberth) | It already writes to a bucket, so it could just be a package that fetches from channels.nixos.org or something | 14:07:25 |
| K900 | Honestly I'd much prefer the whole CNF database to exist outside of the channels entirely | 14:07:01 |
| K900 | And probably not be versioned at all | 14:07:14 |
| K900 | And be updated incrementally | 14:07:23 |
