|
Each package does use the same amount of space as with other packaging methods, but when you upgrade things, Nix won't garbage collect it you can run it manually, from schedule, there's also an option to have nix run it on every invocation (kind of like git does). Anyway I wanted to also to make comment to GPs explanation. What is written, is how Nix is currently addressing each package (it's a hash computed based on source code, dependencies, system, compile options etc). In many cases different options or change in source files can still produce the same exact package, but under a new hash. Nix has an optimise-store command that scans its store and if two packages have exact same result it uses hard links. That similarly can be run via schedule. This ensures that duplicates do not occupy extra space. Though in context of nix, what is referred as content addressed is the new way Nix planning to address the package. Instead of computing hash from package and its dependencies it computes hash based on the package's contents. That solves many problems with the old way, but of course question is how is it done, because it kind of is impossible to get hash of something that you did not produce yet. Of course like everything of this kind, it's possible to do if you cheat a bit. Package is first compiled with a dummy paths, then hashed, then references to those paths are substituted. Here's more about [1]. Having said that, in the blog article when they use "content addressable" it looks like they still meant the current way of doing it (it looks like proper term is input-addressable), not the new way, but if you search "nix content addressable" you are likely find articles about the new way and things might get confusing. [1] https://www.tweag.io/blog/2020-09-10-nix-cas/ |