logoalt Hacker News

jolmgtoday at 2:47 AM1 replyview on HN

> The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages.

The package dependencies aren't based on whether what's packaged is a linked library, and built packages are linked to the dependencies by the digests. The digest of a package is made from the store derivation which contains the digests of the dependencies. Or does the digest of a package not depend on the digests of its dependencies anymore?

Because if they do, then on changing any minor thing, like a typo on a manpage, it would cause the change to cascade by changing the digests of its own package and its dependants recursively. Meaning, none would be found prebuilt and would need to be recompiled.

EDIT: s/hashes/digests/ because that's what appears to be the conventional name for the base32 strings used to identify an entry in /nix/store. The site has changed a lot in the last decade, but I do see this in the thesis that confirms what I remembered:

> The store derivation in /nix/store/1ja1w63wbk5q...-hello-2.1.1.drv is shown in Figure 2.13. It lists all information necessary to build the component, with references to the store derivations of dependencies [...] The output field specifies the path that will be built by this derivation, if and when it is built. It is computed essentially by hashing the store derivation with the output field cleared. --- https://edolstra.github.io/pubs/phd-thesis.pdf

EDIT 2:

> I modify udev rules and the system rebuilds in seconds.

Maybe there's a beaten path for udev rules, a way to override them without modifying the package / store derivation. Or maybe the derivations you're modifying don't have many dependants.


Replies

colordropstoday at 7:21 AM

I didn't say anything about linked libraries. I was just using glibc as an example. I could have used a man page too.