8.1 The problem nixpkgs overlays solve

You patched one package with override, but now you need that patch in every package that depends on it, directly and indirectly. This video shows why override and overrideAttrs cannot push a change down the dependency tree, and why nixpkgs overlays exist. If you use flakes and think the follows mechanism replaces overlays, this lesson explains what you are missing.

In this video

• Injecting a security patch into libc for one app with override: easy and clean
• The same patch for an app that also pulls libc in through boost: watch the code duplication pile up, level by level
• The structural limit: override and overrideAttrs move up the dependency tree, never down
• What happens when only some parts of the tree get the patched library, and why the failure shows up at runtime instead of at build time
• What overlays promise instead: change all packages at once or patch surgically, add new packages, and compose customizations from different teams

After this lesson

You understand exactly which problem overlays solve and why the override chain approach collapses on real dependency trees. The next lessons show the mechanism itself.

Builds on: override vs overrideAttrs (6.4)