Hello! I want to preface all this by saying this is not a huge priority to me. pause/resume would just be a nice quality of life improvement.
Ludovic Courtès <l...@gnu.org> writes: > First, note that the daemon is unaware of “packages”, it only knows > about “derivations”. Agreed. I was thinking mostly about the best interface for a user. But if derivations are too low-level I can see not being able to use the package name. > Second, ‘guix processes’ is nice but it uses low-level heuristics to > determine what daemon sessions are open, what their clients are, and > what they’re building; it resorts to heuristics because the daemon as it > stands doesn’t have a way to communicate its current state. It works > well in practice, but still I wouldn’t go too far building around it. > > Last, you’d need to send SIGTSTP to the whole process group of the > build, like so (I think, haven’t tried): > > sudo kill -TSTP -123 Ah right, I got that advice on IRC also but I don't actually know how to do it. Thanks! > where 123 is the “SessionPID” shown by ‘guix processes’. However, doing > so may affect build results: processes in the build environment might > handle SIGTSTP specially, which can have side effects. It’s an > observable action. I thought of the side effects after sending the email. Makes sense to me. Does that mean it is not worth including? Given that the source and state of a build do not change while paused, if a build tool changes its outputs after paused/resumed is it still reproducible? The other part that would make it difficult is that maybe different build-systems respond differently to different signals. A simpler to implement alternative might just be to provide a way to send an arbitrary signal to the process tree. Given some builds might respond un-reproducibly to it, a warning could be provided. In any case, such a subcommand not a high priority to me as a user, though sometimes I long to pause guix build ungoogled-chromium. Thanks again, John
