| 17 Mar 2024 |
 Robert Hensing (roberth) | I'd prefer for programs.sqlite to be a package like some of the other "data" packages (cabal-hashes, fonts, ...) | 13:48:14 |
| Robert Hensing (roberth) | It will be out of sync, but that's acceptable and worth the cost savings | 13:48:41 |
| Robert Hensing (roberth) | It won't be out of sync by much, if we have a cron job | 13:49:01 |
 infinisil | It's a tradeoff, but I'd rather have things be in sync.. | 13:49:06 |
| Robert Hensing (roberth) | Sure, sync is nice, but why? | 13:49:20 |
| infinisil | Isn't that obvious? If there's a new package I can get it, and I won't get old packages. I also won't get matches for broken packages | 13:50:10 |
| Robert Hensing (roberth) | It's going to be out of sync "by definition" because of build failures anyway | 13:50:21 |
| Robert Hensing (roberth) | If a build fails, it should still be in the programs db, because the failure is probably not permanent | 13:51:02 |
| 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 |
