Code change:
buildInputs = [ alsa-lib <ins> bluez </ins> dbus <ins> fdk_aac ffmpeg </ins> glib <ins> gst_all_1.gst-plugins-base gst_all_1.gstreamer libcamera </ins> libjack2 <ins> libfreeaptx liblc3 libmysofa libopus libpulseaudio </ins> libusb1 libselinux libsndfile lilv <ins> modemmanager </ins> ncurses readline <del> ] ++ (if enableSystemd then [ systemd ] else [ udev ]) </del> <ins> sbc systemd ] </ins> ++ (if lib.meta.availableOn stdenv.hostPlatform webrtc-audio-processing_1 then [ webrtc-audio-processing_1 ] else [ webrtc-audio-processing ]) <del> ++ lib.optionals gstreamerSupport [ gst_all_1.gst-plugins-base gst_all_1.gstreamer ] ++ lib.optionals libcameraSupport [ libcamera ] ++ lib.optional ffmpegSupport ffmpeg ++ lib.optionals bluezSupport [ bluez libfreeaptx liblc3 sbc fdk_aac libopus ] ++ lib.optional ldacbtSupport ldacbt ++ lib.optional nativeModemManagerSupport modemmanager ++ lib.optional opusSupport libopus ++ lib.optional pulseTunnelSupport libpulseaudio </del> <ins> ++ lib.optional (lib.meta.availableOn stdenv.hostPlatform ldacbt) ldacbt </ins> ++ lib.optional zeroconfSupport avahi ++ lib.optional raopSupport openssl ++ lib.optional rocSupport roc-toolkit ++ lib.optionals vulkanSupport [ libdrm vulkan-headers vulkan-loader ] ++ lib.optionals x11Support [ libcanberra xorg.libX11 xorg.libXfixes ] <del> ++ lib.optional mysofaSupport libmysofa </del> ++ lib.optional ffadoSupport ffado; # Valgrind binary is required for running one optional test. <del> nativeCheckInputs = lib.optional withValgrind valgrind; </del> <ins> nativeCheckInputs =  lib.optional (lib.meta.availableOn stdenv.hostPlatform valgrind) valgrind; </ins> mesonFlags = [ (lib.mesonEnable "docs" true)

Related discussion:
text: Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.