| 17 Mar 2024 |
 davidak | i created an issue about package project status, like unmaintained or abandoned. it would be great if you can have a look at some point https://github.com/NixOS/nixpkgs/issues/296646 | 13:12:59 |
 hexa | we are piling on metadata and I'm not exactly sure where to draw the line | 13:36:13 |
| hexa | if something was unmaintained we could as well remove all maintainers | 13:37:09 |
| hexa | if it was abandoned (upstream?) we could should remove it, but there's usually reverse dependencies involved | 13:37:42 |
| davidak | one project says: "looking for new maintainer" | 13:38:22 |
| davidak | that might take weeks or years | 13:38:35 |
 @patka_123:matrix.org | Keeping all this metadata updated manually seems like a recipe for disaster and mistakes imo | 13:42:20 |
 infinisil | It would be great if Nixpkgs had more "postprocessing" steps | 13:43:55 |
| infinisil | Just like programs.sqlite for binary lookup, we could do the same for maintainer status of packages by automatically checking the date of the source and exposing that in some way | 13:44:35 |
| infinisil | How programs.sqlite is distributed is a bit hacky (embedded into the Nixpkgs channel source), but I can imagine better ways | 13:46:09 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
It would be great if Nixpkgs had more "postprocessing" steps The lack of postprocessing is also a feature. It makes it easy to maintain or use a fork of Nixpkgs | 13:47:43 |
| 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 |
