Hacker News Reader

Comment by rhn_mk1 | Hacker News Reader

> packages do not need to depend on the same dependencies

It's a blessing, and a curse. In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check. A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now.

This is similar to the reason that Debian doesn't accept packages which vendor any dependencies (similar to Fedora).

> declarative package specifications

I tried making RPM, .deb, and Nix packages, and I found Nix to be by far the nicest to work with.

View on HN

> In order to ensure the quality for all packages, now you have to keep all versions anything depends on in check

Spot on. This creates a burden of work impossible to handle for any distribution.

What really happens with the "everything goes" packaging (like throwing stuff in docker) is that nobody does security updates for most libraries.

What actually happens is that Nixpkgs usually bundles one version of $THING at a time, but as a user you can use, say, 19.09 as your primary system, but get your compiler from unstable because you need some cutting-edge feature, without worrying about dependency conflicts or unintentionally upgrading something else.

Or maybe your FPGA programming software depends on some ancient version of QT from 2016, so you pull that Nixpkgs in for that package only.

> A bug fix applied to the most recent version doesn't automatically affect packages depending on it, so all of them need to be updated too now.

This is untrue. Everytime that a package is updated, thanks to NixOS declarative build system, all packages that depend on it are also rebuild/updated. Unless you're pinning your derivations, it works even on custom packages created by you.

That makes sense, but every pinned package contributes to the packaging burden. In order to reduce the burden to what traditional distributions have to deal with, pinning would have to be disallowed, which now resembles the traditional approach a lot, with one version per package.

Well, most packages does not pin dependencies. From the top of my head, proprietary packages generally pin dependencies, however in this case it is because proprietary packages are known to broke when a random library updates.

When I was referring to pinning, it is mostly done locally. I do sometimes, for example, pinning a specific package to a specific commit of Nixpkgs, so I can either backport a new version or avoid some change that I don't want to deal at the moment.

While I agree with what you say, the dependency tree becomes more complex, I’ve found the alternative much, much worse. You can also “mimic” the old behavior by just forcing all the libraries to compile against a specific version of a library, thereby simplifying your dependency free again.

In other words, Nix’ approach gives you the choice, while the current approach forces you into a certain direction.

Reply on news.ycombinator.com