Hacker News Reader

Comment by justinsaccount | Hacker News Reader

I'm really interested in NixOS (and guix), but one thing I don't fully understand is how they handle versioned dependencies.

Say I have a service I run that acts as a frontend for something like nmap. So there is pkgs/tools/security/nmap/default.nix that installs 7.70

How do I 'pin' that version? If I vendor that file into my configuration, that could work, but then the buildinputs are

  buildInputs = with python2Packages; [ libpcap openssl ]
    ++ optionals ...

And the dependencies for libpcap and openssl are themselves not pinned to specific versions, so how exactly do I get a reproducible build?

View on HN

So the real versions here is in the `import <nixpkgs> {};` You need to pin it to a specific version or even commit from nixpkgs github repo. So instead of that, you can find the commit that has all your desired versions and pin it that way. with import (builtins.fetchTarball https://github.com/NixOS/nixpkgs/archive/9a5f7b1630c138a82cb...) {};

This way, all your versions of packages will be pinned to this specific revision, and you can also use multiple revisions at the same time.

What is this 'pint' term? I thought it was a typo of 'pin' but you used it twice.

It was just a typo twice. Sorry for the confusion.

Pinning in the Nix world means pinning an entire Nixpkgs. You pin a program and all its dependencies by pinning the whole root of the "ecosystem."

If you want to deal with N separate programs that are each pinned independently, you will point to N different revisions of Nixpkgs.

One NixOS configuration file can point to several different specific revisions of Nixpkgs. This is done with a so called "import from derivation" in the Nix expression language.

You can look at this page (scroll to the bottom to skip backwards compatibility):

https://nixos.wiki/wiki/How_to_fetch_Nixpkgs_with_an_empty_N...

There "pkgs" becomes defined as a specific Nixpkgs revision regardless of which revision is used by "nixos-rebuild" for example.

This would all be clearer with a real example, sorry...

I've got the same confusion as the parent poster, but going a bit further - so does each revision of Nixpkgs have just one version of say openssl? How about if 2 different programs are built around 2 different version of OpenSSL? How do they coexist in one revision of Nixpkgs?

I actually don't really understand how this is handled in other package-managers as well. B/c in the case of libraries, having 2 versions floating around can lead to double linking and duplicate symbols and all sorts of subtle problems.

Nixpkgs does carry more than one version of some packages, but only when the maintainers deem it necessary. These are treated as separate packages with different names.

In the case of OpenSSL, Nixpkgs currently has two packages named openssl_1_0_2 and openssl_1_1, with openssl being an alias for latter.

Different programs depending on different versions can be installed at the same time without conflict. Full paths to dynamic library files are used in binaries instead of relying on a global library path.

So reproducible build means that given the same input (ie same hash of dependencies), you get the same output.

The description of the build inputs has references to the definitions of other packages which have references to the exact version of the source code or commit hash or whatever (and hopefully has a hash of whatever is supposed to be downloaded). Therefore to get a full description one must expand all the other definitions. I don’t know how to do this in guix/nix but I suppose one might say “this package definition with this commit of this repo of package definitions.

Pinning to a specific version seems to be a different issue and I don’t really know anything about that

Reply on news.ycombinator.com