Hacker News Reader

Comment by davexunit | Hacker News Reader

>Do they specify the build dependencies down to some sort of file-based checksum level?

Yes, Emacs 24.4 built with X support has a different hash than Emacs 24.4 built without X support. They are completey different in the eyes on Nix/Guix.

>So, what do you mean when you say "reproducible"? Is it really specific and unforgiving of new versions of things? Or, does it allow for newer versions easily?

In Nix/Guix, you have to specify the exact dependencies, nothing is implicit. Packages are built as a pure function. A package's identity is the hash of all its build inputs: source code, build system, and other dependencies. Bumping the version of a dependency triggers rebuilds of packages that depend on it.

I know of no other package management systems that treat package builds in this manner.

View on HN

"In Nix/Guix, you have to specify the exact dependencies, nothing is implicit."

Do you do psuedo packages, like the Debian model of the build-essential package which pulls in a standard cloud of normal stuff, no need to list libc6-dev by name because that's a dependency of build-essential, but if you want libpcap-dev you need to pull it in specifically by name because its not in build-essential?

While the phrase "nothing is implicit" was used, there actually are so-called "implicit inputs" in Guix. :-P Each package uses a certain "build system" which can be e.g. "gnu" which has e.g. autotools and bash as "implicit inputs" so every package using that build system gets those dependencies.

This doesn't really sound like a feature. Or, at least, not a feature I've ever wished I had.

From a purely pragmatic perspective, it means huge swaths of software have to be rebuilt any time anything gets updated. And, it's become clear now to me that every user is building all their own software (as with ports or Gentoo ebuild, both of which I consider unacceptable package managers for servers for that very reason)...given that, and given that rebuilds now must often span huge piles of software, occasionally with exploding dependency chains, I'm feeling a little queasy imagining trying to administer such a system.

I understand the appeal, from a security perspective (and particularly in a world in which the NSA and other highly capable attackers are willing to exert resources to compromise software at the vendor level), of being able to duplicate a package from source. That's cool. But, why force every user to do so every time they update their software? Am I missing something? Are there also binary packages and being able to verify package builds is optional?

Users do not need to build everything for themselves. They can download binaries from the build farm, just as if they were using a binary-based distro. The system is transparent: If a binary is available from an authorized remote machine, Guix will pull from it. If not, Guix will build it locally.

To respond to security updates to core packages a lot faster, we are using a technique called 'grafting' that doesn't involve full rebuilds.

It's true and it's an interesting problem, maybe in the future a package identity will only be partially dependent on some inputs, the other inputs being second class variables that don't affect the build the same way. Kinda like the difference between parameters and variables in math. Fa(x) is still F even if a = 1 or 2 ,....

Reply on news.ycombinator.com