All dependencies and packages go into the /nix/store/ and are shared.
However you still end up with a lot more bloat than typically, as an upgrade will leave all the old versions behind. This allows you to instantly up & downgrade in case something goes wrong. But it also means you need twice the space. You can of course free the space afterwards, but you still need it for the upgrade.
Another factor that can lead to bloat is that Nix makes no use of binary compatibility, meaning dependencies are specified down to the individual bits, so a package doesn’t just depend on some thing named libfoo, but on a very specific libfoo with a known sha256 checksum.
The official packages in nixpkgs will all use the same libfoo, but if you build your own software or install software from other places you can quickly end up with multiple libfoos around (NixOS can still dedup them a little via hardlinks, but still bloat). You can manually override dependencies, but that’s something you have to do manually, there is no automation as far as I can tell (nix build --override-input nixpkgs 'flake:nixpkgs' should get reasonably close)
This also leads to bigger downloads, as an update to a core library can require updating a large number of upward dependencies.
Overall I think it’s worth the trade-off, as it gives you much more flexibility, but a typical NixOS install will generally still end up bigger than regular distributions.
All dependencies and packages go into the
/nix/store/
and are shared.However you still end up with a lot more bloat than typically, as an upgrade will leave all the old versions behind. This allows you to instantly up & downgrade in case something goes wrong. But it also means you need twice the space. You can of course free the space afterwards, but you still need it for the upgrade.
Another factor that can lead to bloat is that Nix makes no use of binary compatibility, meaning dependencies are specified down to the individual bits, so a package doesn’t just depend on some thing named libfoo, but on a very specific libfoo with a known sha256 checksum.
The official packages in
nixpkgs
will all use the same libfoo, but if you build your own software or install software from other places you can quickly end up with multiple libfoos around (NixOS can still dedup them a little via hardlinks, but still bloat). You can manually override dependencies, but that’s something you have to do manually, there is no automation as far as I can tell (nix build --override-input nixpkgs 'flake:nixpkgs'
should get reasonably close)This also leads to bigger downloads, as an update to a core library can require updating a large number of upward dependencies.
Overall I think it’s worth the trade-off, as it gives you much more flexibility, but a typical NixOS install will generally still end up bigger than regular distributions.