On 2025-08-04, Andreas Enge wrote: > Am Sun, Aug 03, 2025 at 10:02:29AM -0700 schrieb Vagrant Cascadian: >> Any chance we could merge ncurses/tinfo into ncurses? >> I think there are ~6 packages that depend on it, but it would trigger a >> lot of rebuilds because of ncurses changing... > > Why not! Could you prepare a pull request to reference it?
I could! That is truely and trivially the easy part... > (Which would also mean that you take responsibility for the issue.) $ guix refresh --list-dependent ncurses Building the following 14564 packages would ensure 34336 dependent packages are rebuilt: ... Is that even an appropriate scale for a staging branch anymore? I have lost track of such things with the new team-focused branching strategies... I do not think I would be able to tackle that alone... I am not even sure I have any machines with sufficient disk space to test that. Not sure how the various CI and QA infrastructures are doing at the moment to handle that kind of rebuild... I suspect it is very low risk, as it merely adds another target to ncurses... but I am not so naive to assume that! In particular, I am not sure how this would affects grafts for ncurses... presuming there are any? Would it effectively ungraft them? Would it be good to ungraft things at the same time? ... largely clueless about how to even check that. Any way I could get an easy view of the current status of those 34k+ packages, to even know how many are currently building? That said, just not poking the beehive with a stick is a perfectly tempting option... it is a small number of packages that use ncurses-with-tinfo (according to guix refresh, 58 packages) but it would also be nice to not build a special ncurses variant just for them... live well, vagrant
