Code change:
, lilv , makeFontsConf , nixosTests <del> , withValgrind ? lib.meta.availableOn stdenv.hostPlatform valgrind </del> , valgrind <del> , libcameraSupport ? true </del> , libcamera , libdrm <del> , gstreamerSupport ? true </del> , gst_all_1 <del> , ffmpegSupport ? true </del> , ffmpeg <del> , bluezSupport ? true </del> , bluez , sbc , libfreeaptx , liblc3 , fdk_aac , libopus <del> , ldacbtSupport ? bluezSupport && lib.meta.availableOn stdenv.hostPlatform ldacbt </del> , ldacbt <del> , nativeHspSupport ? true , nativeHfpSupport ? true , nativeModemManagerSupport ? true </del> , modemmanager <del> , ofonoSupport ? true , hsphfpdSupport ? true , pulseTunnelSupport ? true </del> , libpulseaudio , zeroconfSupport ? true , avahi , raopSupport ? true , openssl <del> , opusSupport ? true </del> , rocSupport ? true , roc-toolkit , x11Support ? true , libcanberra , xorg <del> , mysofaSupport ? true </del> , libmysofa , ffadoSupport ? x11Support && lib.systems.equals stdenv.buildPlatform stdenv.hostPlatform , ffado , libselinux }: <del> # Bluetooth codec only makes sense if general bluetooth enabled assert ldacbtSupport -> bluezSupport; </del> stdenv.mkDerivation(finalAttrs: { pname = "pipewire"; version = "1.2.1";

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.