Is the process of packages building with dependencies documented somewhere. I have read about the hashes, avoiding DLL hell, but not found anything that helps me understand what happens.
This is my scenario that led me to realise I don’t know…
If I have a package foobar that has dependencies (foo and bar) what happens when the derivation is built?
Specifically, I’ve been trying to debug my kdiskmark instance which uses fio (a cli app). Calling fio gives the error:
The program ‘fio’ is not in your PATH. It is provided by several packages.
Is this “just a path issue”. If I add fio to system packages will there be 2 copies, or just 1 (assuming that the same version suffices).
I hope the above makes sense for what I am trying to understand…
If it’s the same exact package, you won’t get 2 copies by putting it into
systemPackages. The nix store path is the same, so it gets deduped.
And putting a package into
systemPackages never puts its dependencies into there. Packages are set up to find their dependencies by their nix store path, hardcoded at build time, so they don’t depend on things being in
PATH at runtime. (Mostly. There are some exceptions, when a dependency is huge and rarely needed.)
Try testing this yourself! Add it to
systemPackages, check it out with
realpath $(which fio) and
ls or something against
@pxc - I did have a play, but I wasn’t sure if it was a complete test (only finding one instance does not prove there is only 1), so wasn’t sure that my interpretation was correct.
I didn’t know about realpath…
Yeah, that totally makes sense!
There are some circumstances under which you do end up with multiple copies of something in the Nix store, btw. You’ll likely get a feel for them as you continue using Nix.
readlink -f) are not necessarily available with all coreutils implementations, but they are there in the GNU one, so you usually have them on Linux, at least.
realpath together are great for quickly checking the exact store path you’re using when you’re on a system that might have multiple binaries available.