| 31 Mar 2025 |
 emily | we could also ship a patching interface that works with both old and new packaging in 25.05 | 21:06:06 |
| emily | to help a transition to that | 21:06:15 |
| emily | just like we do with lib changes | 21:06:21 |
 John Ericson | On the level of really slowing down and listening, I feel like all the upset about the new packaging has been on things that are not actually the split itself | 21:06:47 |
| John Ericson | And just about everything I've done in Nix and otherwise since 2022 and those RFCs, has been about layering the separate and cool down a bunch of issues | 21:07:35 |
| emily | I agree with that. I have no objection to splitting up the packaging by itself | 21:07:46 |
| John Ericson | and, having not been the one doing the Nixpkgs stuff, and just doing the in-tree stuff, I was under the mistaken impresssion that it was fine | 21:08:05 |
| emily | it's the specific way it's done and the communication around it and the timing and the lack of attention to back compat | 21:08:10 |
| emily | i get that this is frustrating on your end too but the first most of us heard of this packaging was when 2.26 got merged with it | 21:08:40 |
| John Ericson | and so now it's painful to see when I felt so close to being done these herdles | 21:08:41 |
| emily | just like the first we heard of the plan to do another Nix bump was when a comment got edited a few hours ago | 21:09:00 |
| John Ericson | hell, even when I am doing other things in Nixpkgs like the compilers and hte libs and whatnot, it is often breaking up packages into smaller packages | 21:09:09 |
| emily | and I let the packaging topic drop since I've had other commitments and shipping a problematic nixVersions.latest isn't the end of the world even if ideally avoidable | 21:09:58 |
| emily | if I'd known it was going to go fix cross -> bump latest -> bump default over a few days leading up to freeze I'd have pressed the points harder | 21:10:32 |
| John Ericson | fix cross is good, right? | 21:11:38 |
| emily | of course. though the first time it broke the channel but that's on our current CI | 21:12:03 |
| John Ericson | I depsartely need to eat in a moment, but also, what exactly do you (and anyone else) imagine the split package is going to break? | 21:12:03 |
| John Ericson | (we've seen the issues with the combo packgae and symlinks) | 21:12:13 |
| emily | my point is that it was totally unshippable days ago | 21:12:18 |
| John Ericson | (those are now fixed but there could be more) | 21:12:22 |
| John Ericson | I am not contesting that | 21:12:44 |
| John Ericson | I am basically asking "if we make it shippable, are there more unknown-unknowns, or is it good now?" | 21:13:06 |
| John Ericson | IMO risk from unknown-unknowns and risk from known-knowns like "wtf is this unreadable code" are quite different | 21:13:50 |
| John Ericson | the latter can just be fixed, and then it's good, the former is what needs time to incubate | 21:14:02 |
| emily | In reply to @Ericson2314:matrix.org
I depsartely need to eat in a moment, but also, what exactly do you (and anyone else) imagine the split package is going to break? overrides are the big one, esp for patches. and yes, the output shimming seems brittle to me, e.g. I am not sure it works with ^ or the like? the other thing is that the support code is complicated beyond any other non-compiler package set I've seen, but maybe devendoring will help that | 21:14:13 |
| emily | is it really so unreasonable to want to see one uneventful early-cycle Nix bump before we start doing them in the lead up to release coupled with breaking package rewrites? | 21:15:20 |
| emily | even 2.24 took a couple tries to stick | 21:15:30 |
| emily | and I advocated for that bump | 21:15:37 |
| emily | because I don't think the drift is good for the projects | 21:15:49 |
| emily | but the only way to solve the root cause is proactive communication and prioritization of Nixpkgs' needs and concerns for a critical component | 21:16:19 |
