[Nix-dev] Re: Package maintainer coordination problem and Nix

[Ludovic Courtès]

Hello, and welcome to Nix(OS)!

Mads Lindstrøm <mads_lindstroem at yahoo.dk> writes:

> That said, when looking at the way packages are organized in the Nix
> subversion repository
> (https://svn.nixos.org/websvn/nix/nixpkgs/#_nixpkgs_), package
> maintainers must still do as much coordination as package maintainers in
> traditional Linux distributions. That is, if I upgrade Glibc in the
> subversion repository, I risk braking packages that depends upon Glibc.
> In other words, if package X depends upon library Y, it is _not_ stated
> explicitly which version of library Y.

It is.

In, say, Debian, packages specify their dependencies using symbolic
names.  What these names refer to varies over time.  E.g., at some
point, `libc6' may refer to Glibc 2.7, and at some later point, it may
refer to Glibc 2.9.  A package can also refer to a "fully-qualified"
package name, e.g., `libc6-2.9', but there's no formal guarantee that
this always points to the same variant of the Glibc build.

In Nix, packages are built by functions ("Nix expressions"), whose
arguments are the package's dependencies and (possibly) configuration
options.  Dependencies are represented using opaque objects
("derivations") that point unambiguously to a specific instance of that
dependency; on the file system, build results are stored in unique
"store paths".  Changing a single bit in how a package is built leads to
a different derivation, i.e., a different "name".

For instance, building GNU Coreutils with a given instance of Glibc may
lead to the following store path:

  /nix/store/b7h0m59pa845hvp04a6xp2shv41y88l5-coreutils-7.2/

Building it with a different Glibc or different configuration options
leads to a different path:

  /nix/store/mhzhy58bbhg3yzhvm2lskylb4hfw9wcv-coreutils-7.2/

The store path comprises a hash of all the build inputs of the package.

All this is better explained in the various papers at
http://nixos.org/docs/papers.html .

> This leads me to the question, is Nix specifying dependencies optimally?
> If each package, in the Nix subversion repository, explicitly stated
> which versions of packages it depended upon, then upgrading library X
> would be safe.

It's actually better than this.  ;-)

Look at, say,
https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/libraries/cil/default.nix .
This file contains a function that builds the CIL package, and whose
`perl' and `ocaml' arguments actually point to store paths, as
illustrated above.

Jumping to the call site of this function (search for "cil =" in
https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/top-level/all-packages.nix)
tells you which actual parameters were passed.

If you search for the definitions of `ocaml' and `perl' that are in
lexical scope (search for "ocaml = " and "perl =" in this file), you get
to know how these arguments were computed.

IOW, the Nixpkgs source tree reflects a full dependency graph, with
complete information on how each node was built.

Hope this helps,
Ludo'.