| 12 Oct 2025 |
|  midischwarz12 set a profile picture. | 02:45:11 |
 lovesegfault | (i made the test agnostic) | 02:46:01 |
| midischwarz12 | Yea, you're not technically wrong that packages on the same version of nixpkgs could have different versions. But you'd have to have a package for every version of its dependencies as well. At which point, it is usually easier to dig through git or just override the package with a different version of source. That said, you'd have to do the same for its dependencies as well. But it's much easier to push this unto the user than force all of the nixpkgs maintainers to keep every package up to date. That said, I do agree that there should be an easier CLI interface to dig through nixpkgs and find necessary package versions or versions within requirements such as version ranges | 03:26:54 |
| midischwarz12 | So for some packages, yes, we do support multiple versions b/c we need to in the current version of nixpkgs (clang, python, gcc, glibc, etc). But for most packages, that is very unnecessary to maintain the current round of packages in nixpkgs | 03:28:01 |
 tavinator | Thanks midischwarz12 I guess I am just looking for a framework to approach the problem. I would not have minded contributing the code to nixpkgs for packaging specific old versions of this or that. But it was pointed out to me that it would have an infeasible impact on Hydra -- a piece of the puzzle I wasn't seeing until now.
override the package with a different version of source.
Sounds like what I am looking for... this means using "overlays" then?
| 09:22:08 |
|  0x9t joined the room. | 09:55:46 |
 John Ericson | @lovesegfault:matrix.org: we make tests require a new enough daemon version all the time | 14:04:52 |
