Mutiple replaceRuntimeDependencies may reintroduce depenendices

[roconnor]

replaceRuntimeDependencies is implemented by doing a fold over the list of runtime dependency replacements. The issues is that after replacing one depencency, say bash, with an updated version, the next replacement might replace say firefox, with an updated version that depends on the old bash. This is probably unexpected from the user's perspective and could cause dangerous surprises if a user is using this as a security update mechanism.

I should say that this is only a theoretical issue; I haven't verified this acutally happens, but I wanted to file an issue before I forget about it.

One possible solution is to do some sort of topological sort of the list of replacements based on the dependency order of the "new" packages on the "old" packages so that outermost dependencies are replaced first. But some since "new" packages may have completely different run-time dependencies some though is needed to make sure this works right.

I think a better solution is to come up with an elegent way of simulateously processing all replacements directly in the replaceDependency code, but I would need to sit down and think about how to do this.

[shlevy]

I won't object to a good implementation of this, but IMO replaceRuntimeDependencies is mostly useful as a stop-gap and should be replaced by a proper rebuild once packages are available, so the frequency of having two packages to replace at the same time is low enough not to prioritize this. I'll unassign myself, but please do let me know if you have a good way to do it.

[Profpatsch]

(triage) @roconnor Do you still want to follow up on this?

[Profpatsch]

No response, so close @zimbatm.

[zimbatm]

This is going to be replaced by a proper solution soon (hopefully). See #14000 and related work.

[nbp]

This issue would be fixed by #10851 , because the patching mechanism works by constructing the patches out of all the fixed packages, instead of chaining independent replacement of dependencies.

I even have a test case which I used to verify that #10851 is working properly:
https://github.com/nbp/nixpkgs-2/blob/08f53825e305bbaf4610cf9c5b0d2dad102108cc/pkgs/test/security/check-quickfix.nix