To reproduce:

$ nix path-info -r (nix-build '<nixpkgs>' -A duplicity) | grep mesa
/nix/store/0inxqcjpcfw1syksd7d3w6s0kzm6g897-mesa-20.3.4-dev
/nix/store/a71113rnbykvfmapskscmivnd8i8bcqx-mesa-20.3.4
/nix/store/vh0k8fflhd32mvjb717k3alnsl33hwil-mesa-20.3.4-drivers

duplicity is a small command-line backup program, so this is a bit surprising to say the least. Even if it depended on some graphics libraries, I would have maybe expected glvnd to show up. But the actual mesa drivers is a bit too much. There seem to be several surprising issues here:

1. The python wrappers automatically add the whole build-time PATH from the propagated build inputs to the wrapper. WIP: Python: wrap and patch using requiredPythonModules instead of propagatedBuildInputs #102613 might help a bit here.
2. cairo puts a whole lot of libraries into propagatedBuildInputs, including libGL. Even if they don't end up in the wrapper, they are written to nix-support/propagated-build-inputs.
3. libGL.dev then depends on the mesa drivers, because the mesa pkg-config files depend on the drivers.

I don't really know where to start fixing this issue.

• Should cairo have fewer propagatedBuildInputs?
• Should propagated build inputs only be included in the dev output? If the bin output includes the nix-support/propagated-build-inputs file, then the closure includes all propagated build inputs, even if they are not referenced.
• Is there a way to prevent propagation of (some) propagatedBuildInputs? Presumably python3Packages.pygobject3 doesn't need to propagate dependencies from cairo (which are only necessary to build C programs).
• The mesa dependency on the default driver set is probably a bug?