Hmm, @abbradar -- perhaps we should go ahead and take the time to make this multi output? Based on criu-3.9 it looks like we could at least have ["out" "man" "lib" "dev"].

(Ideally the python libcrui package should be split out too but that's a whole separate can of worms, probably.)

Either way this isn't a blocker, just a suggestion.

I personally don't see a reason for splitting outputs unless we have huge closure sizes

criu has a closure size of ~120mb which IMO is large enough to justify it -- in fact, all outputs should be multi-output to the extent they can be, even if that only includes [ "out" "man" ]. It makes the various expected "results" of a derivation more obvious to any reader of the code (this explicitness is good enough a reason on its own). But also I've had several cases where package updates have variously caused things like $man outputs to fail to be populated/created, causing a build failure and avoiding committing a regression with routine updates. Whereas a no-multi-out derivation would have just succeeded without more careful investigation of the build logs indicating something was wrong (because if $out/man doesn't get created for some reason that's no big deal, but in a multi-out expr, mkDerivation gets mad about $man not existing when it's finished -- or the build tries to move files and doesn't find any and fails in a custom installPhase, etc.) This is all aside from closure reduction benefits for users.

However, on further evaluation, most of this closure size for criu comes from Python, and Python is a necessity here due to the fact that bin/crit is a Python script. So there's no real way to reduce size of the main out output. And Python is pretty popular so it's likely it already sits in your store, anyway.

But I still think splitting dev/lib/man is good practice and it would still apply here. Either way, there's no reason to block this on it.

@thoughtpolice Good idea, did that and also gave a bit more love to the package (default buildPhase now and all).