Nixpkgs: Top-level nixpkgs-headless package set

[copumpkin]

Short of https://github.com/NixOS/nixpkgs/issues/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:

https://github.com/NixOS/nixpkgs/blob/bd545892332ede39cd5c1c0ba26e7101b0d2c971/nixos/modules/config/no-x-libs.nix#L29-L39

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)

[copumpkin]

Note that although USE flags are cool and all, I really don't want a combinatorial explosion of these optional package sets, so I'd rather roll the "no audio/video" into a single flag and start there, see how it works out, and then possibly start expanding to other flags like that, rather than front-loading a bunch of options folks might want to toggle. This seems like the one with the biggest bang for the buck.

[georgewhewell]

+1 for this. FYI, the noXlibs option does not actually prevent xlibs from being installed when networking.networkmanager.enable = true; is set, since the module references networkmanager_strongswan, which doesn't support any 'headless' build. I'm not sure if this is broken behaviour since noXlibs documentation doesn't specifically mention networkmanager, but it seems to be the intention of the module.

[vcunat]

Maybe we should standardize a parameter name for this, so that we didn't have to keep this in a list that's "far" from the actual package definitions. (Then you'd simply map over all packages and call .override on all that have the name among parameters.)

Anyway, the main thing missing is people defining these "light" variants meaningfully and testing them. It might still be rather hard to have one "light" to fit all. (and CI on Hydra, if "we choose" to spend resources on that)

[edolstra]

I don't understand what's being proposed here. What is a "top-level nixpkgs override"?

[vcunat]

@edolstra: I assumed it meant to add an attrset into pkgs/top-level/all-packages.nix that would contain the whole nixpkgs but with an additional set of overrides applied to it.

[copumpkin]

Yeah, that's it.

[FRidh]

Will it be an attribute that is an overlay?

[copumpkin]

Yeah, something like that. I was thinking along the lines of:

# headless-overlay.nix
self: super: {
  # blahblah, the same sort of thing that's currently in no-x-libs.nix today, probably fleshed out a bit
  attribute-to-appease-github-syntax-parser = true;
}

```nix

all-packages.nix

{
# ...

headless-overlay = import headless-overlay.nix;

# Hydra should build this
headless = lowPrio (recurseIntoAttrs (import self.path { overlays = [ self.headless-overlay ]; }));

# ...
}

```nix
# no-x-libs.nix
{
  # ...

  nixpkgs.overlays = pkgs.headless-overlay;
}

I'm not a fan of using pkgs.path but I don't know how to add an overlay to an existing package set. Apart from that, how does it sound?

[Ekleog]

(triage) is this going anywhere? I can't read whether a decision has been taken, be it in favor or not.

[oxij]

Related to #56110.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.