Hacker News Reader

Comment by inahga | Hacker News Reader

What's been driving me batshit is when nixos-rebuild decides it wants to build from source. I just burned an hour the other day trying to update, and getting stuck because Nix decided my little old laptop needed to compile node.js from source. Had to trial-and-error remove packages to figure out which one was transitively pulling in node.js.

It turned out to be ansible... which is a pure python tool. Beats me.

There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM.

I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.

View on HN

Less than a week ago I complained about nearly the exact same issue and received the typical “nixy” response “that’s what the cache is for”. Well, that’s excellent news, when the cache actually works as expected. I see this a lot with my flake.nix per repo configurations too. The flake.nix never changes, yet it inexplicably rebuilds packages sometimes

I've been wondering about that too.

I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild?

I don't know.

I try to `nix flake update` my system configuration every 2-3 months.

Arguably, running Arch and not updating frequently is a pain, too.

> eventually the nixpkgs of the project is garbage collected

You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)

Are you saying that the presence of a result/ symlink means the sources are kept, and if I remove the result/ symlink, it gets gc’ed?

Yes, gc root links are accounted at the moment they are written by nix and they retain the graph while they are continue to exist.

This happened across the board to everybody as there was some change that went into unstable that broke 1000s of packages, everybody was rebuilding nodejscause it failed to build (thus wasn’t in the upstream cache). It’s a good idea to pin you nixpkgs with with flakes or fetchgit in your config and not use channels. Or stick to stable(can’t do this on macOS as easily though, this is where I learned this).

You can use hydra to observe the ebb and flow of broken packages getting fixed and pick good git hashes to pin to. Once I figured that out I was very happy and had a good time glancing through hydra to monitor this. Now I can make informed decisions about what hash I build from and still keep unstable train, upgrading more often then I was before.

> Had to trial-and-error remove packages

There are introspection tools for that.

> Build from source

That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)

Reply on news.ycombinator.com