Short of #12877, which is a bigger job, we already have (implicitly) a notion of headless packages in NixOS today. If you import minimal.nix, you find it goes into no-x-libs.nix which contains this gem:

Which is basically a super ad-hoc headless package set, disabling X in a few places. minimal.nix does appear to get forced as part of NixOS testing, but none of those jobs show up as distinct entities, so we'd never really notice if they broke except in that they might hinder a test, possibly by accident.

What if instead we took the snippet above from no-x-libs.nix and made it a top-level nixpkgs override, something like nixpkgs.headless, with the contents of the expression above in it. As a first-class concern, we could now flesh out what it means to be a headless package (e.g., no sound or video, suitable for servers) and then Hydra would build these packages for us. Even though it's a full package set, the overrides would obviously only cause rebuilds of packages that use X or audio.

I was stumped for a while why my EC2 boxes were building so much stuff, and eventually I realized that the minimal.nix profile was overriding packages and causing me to have to rebuild a bunch of stuff.

Any objections to me adding something like nixpkgs.headless and then referring to that from no-x-libs.nix? Or a better approach?

cc @edolstra as overseer of the Hydra infrastructure (which would get stressed a bit more by building multiple copies of some packages that use X and audio)