Generally you don't specify a specific version as a dependency unless it's necessary, but when 'building' the system, specific versions are used. If things break during an upgrade you can roll back to the previous version. Keeping those older builds around will mean keeping older versions of the packages used in those builds (libcurl, for example). Periodically, you can purge older generations (i.e. builds) and collect garbage, which will clear out packages that aren't used anymore. It would be very strange to end up in a situation where you had dozens of instances of libcurl _being used simultaneously_ (though I guess that would be possible if lots of packages had very special requirements, and ended up building libcurl with different flags or something).
There may be circumstances where you have a _specific_ version dependency, and you can specify that too. That would mean having multiple copies of the same package, even in a single generation. Obviously this usually means major versions, so you don't usually see _dozens_ of them. Having specific dependencies on minor versions would be a major code smell IMHO.
Anecdotally, my NixOS systems (both desktops and servers) can grow up to, say, ~50 gb of system files in a few months, at which point I'll clear out older generations and GC, which gets them down closer to a typical Linux distro size. Once or twice, I've seen a system balloon up over 100G when I was doing a lot of experimenting with packages.
Oh, and incidentally, most of the different versions are only visible to the packages that depend on them. Your 'default' environment is one such package, and only sees one of each of it's dependencies. It's not like you have dozens of instances of packages crowding /lib or anything (since /lib doesn't exist in the first place). You have to go looking in the Nix package store to find the actual files.
Nixpkgs doesn't wontonly package multiple versions of libraries. But as you upgrade you will accumulate old builds of libraries until you GC. The meaningful question is not how many of X do you have installed, but whether you have multiple versions of X reachable from GC roots.
It could, depending on your use case, but normally all packages from nixpkgs share the same libcurl, so when libcurl is updated, all packages that depend on it will also be updated.
The old libcurl will still exist on your system to allow you to rollback to previous states of your system, but you can always run nix-collect-garbage if you want to free up disk space.
This is similar to the situation in Arch Linux where pacman keeps all downloaded packages, and you have to run paccache if you want to free space.
If any of software relies on different versions, yes. It beats not being able to use something because you can only have one version of a library shared.
How does this work with compiling software. For example, I routinely compile programs that use different versions of openssl. Does NixOS make this process any easier.
Yes that's one of the greatest things about nix. You can have 100 pieces of software installed that all use a different curl version without issues. You can also develop 100 piece of software/compile that all use a different curl version at once.
Not repeating the others:
If a package does end up using multiple version of the same lib, nixos can even deduplicate it somewhat, by symlinking one’s documentations to the other’s.
There's an optimzation I'm aware of where nix will de-duplicate individual files with hard links. This wouldn't be safe in almost any other context, but is safe with nix because the files are immutable. So you have have 100 variations of libcurl and only "pay" for the unique files.
Generally you don't specify a specific version as a dependency unless it's necessary, but when 'building' the system, specific versions are used. If things break during an upgrade you can roll back to the previous version. Keeping those older builds around will mean keeping older versions of the packages used in those builds (libcurl, for example). Periodically, you can purge older generations (i.e. builds) and collect garbage, which will clear out packages that aren't used anymore. It would be very strange to end up in a situation where you had dozens of instances of libcurl _being used simultaneously_ (though I guess that would be possible if lots of packages had very special requirements, and ended up building libcurl with different flags or something).
There may be circumstances where you have a _specific_ version dependency, and you can specify that too. That would mean having multiple copies of the same package, even in a single generation. Obviously this usually means major versions, so you don't usually see _dozens_ of them. Having specific dependencies on minor versions would be a major code smell IMHO.
Anecdotally, my NixOS systems (both desktops and servers) can grow up to, say, ~50 gb of system files in a few months, at which point I'll clear out older generations and GC, which gets them down closer to a typical Linux distro size. Once or twice, I've seen a system balloon up over 100G when I was doing a lot of experimenting with packages.
Oh, and incidentally, most of the different versions are only visible to the packages that depend on them. Your 'default' environment is one such package, and only sees one of each of it's dependencies. It's not like you have dozens of instances of packages crowding /lib or anything (since /lib doesn't exist in the first place). You have to go looking in the Nix package store to find the actual files.