Run time closure of duplicity includes mesa drivers

[gebner]

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. #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?

[FRidh]

We need to get rid of propagatedBuildInputs for Python packages entirely. https://github.com/NixOS/nixpkgs/pull/102613 shows how it could be done. After an RFC discussion on overriding of derivations I concluded we should use less Nix and instead use a file such as $out/nix-support/python-packages so https://github.com/NixOS/nixpkgs/pull/102613 won't go in.

[gebner]

Some other surprising observations:

1. propagatedBuildInputs = [ pyobject3.out ]; means exactly the same as propagatedBuildInputs = [ pyobject3 ];. So you always have a dependency on the C headers of a python extension, whether you want them or not.
2. Adding outputs = [ "out" "dev" ]; to duplicity breaks the python wrapper.

[gebner]

Related: checkInputs are in the runtime closure as well #118452

[FRidh]

Should update https://github.com/NixOS/nixpkgs/issues/1819 again, its been a while.

[FRidh]

Adding outputs = [ "out" "dev" ]; to duplicity breaks the python wrapper.

This was noticed in the past with if I recall correctly requests and some other packages. A work-around is to use pythonPath instead of propagatedBuildInputs.

[SuperSandro2000]

Can this be closed?

[gebner]

Can this be closed?

I've fixed the closure size in #118459 and the mesa issue in #118479. But I'd still like some comments on propagatedBuildInputs.

• Is cairo's use of them excessive?
• Is there a way to prevent propagation?
• Splitting into multiple outputs helps a bit here, because the propagated-build-inputs file is only put in the dev output. Does this mean that every package which transitively depends on a propagatedBuildInput should have a dev output?

[FRidh]

1. https://github.com/NixOS/nixpkgs/pull/102613#discussion_r518265183. It could use a PR.
2. https://github.com/NixOS/nixpkgs/pull/102613
3. This confuses me. The dependent will not create a propagated-build-inputs, unless it also declares propagatedBuildInputs.

I should write out once how things work now and what should change.

[gebner]

This confuses me. The dependent will not create a propagated-build-inputs, unless it also declares propagatedBuildInputs.

Then I was also confused, sorry. This behavior sounds great, actually. If we move python away from propagatedBuildInputs, then this issue will be automatically gone.