| 31 Mar 2025 |
 emily | in which case we would be free to break the old way in 25.11 | 21:18:14 |
 John Ericson | because we can simply test all the things you mentioned right away | 21:18:20 |
| John Ericson | there aren't really latant issues | 21:18:24 |
| John Ericson | you mean a patching mechanism that works with split and unsplit packages? | 21:19:26 |
| John Ericson | I am not sure, probably not | 21:19:31 |
| emily | how people consume our packages is a tragic unknown. though of course we always have to draw a line somewhere but look at how breaking changes to lib are handled for how our caution should increase as the criticality does | 21:19:36 |
| emily | and again if we were keeping packaging constant but bumping version or vice versa (not possible in this case, I know), there would still be concerns but of lower magnitude | 21:20:18 |
| John Ericson | I'm thinking about it | 21:28:38 |
| John Ericson | (but I also walked out to eat) | 21:34:03 |
 trofi | I wonder what it would look like if every single nixpkgs package had their own unique helper to apply patches and change depends :) | 21:35:47 |
 Robert Hensing (roberth) | it's a package set | 21:49:10 |
| Robert Hensing (roberth) | actually I think it would be great, because we'd settle on a standard interface for doing just those things and nothing else, and we'll finally have an interface boundary | 21:49:57 |
