[colordrops]

That problem is overstated. I've been dozens of custom packages and modules and it's not that much more complex that basic Nix config, and in fact is a huge positive, not negative. How easy can you write config that packages a binary and/or sets up a new service reproducibly? I'd much rather do that on Nix than Ubuntu or Arch for sure.

[jolmg]

If you modify a base package, like maybe to apply some minor patch on a systemd executable as an example, is there a way to avoid having to recompile basically all installed packages (for being at least indirect dependents)? Had a problem like that about a decade back.

[colordrops]

No, it doesn't recompile everything, that's not how Nix works. The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. Something else must have happened. I modify udev rules and the system rebuilds in seconds.

That's the great thing about nix, it should actually compile LESS than other distros, because, you can have multiple versions of the same lib on the same machine. You just create another version of the package and only patch the packages that need it. You don't even have this option on other distros. Name one other distro that lets you run multiple versions of glibc natively (not containers or flatpaks or whatever).

[jolmg]

> 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.

[colordrops]

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

[jolmg]

Was trying to figure out why you said that it wouldn't happen with a systemd executable but it would with glibc. Figured it being a library was the difference you meant. Maybe you just meant that glibc has more dependents.

[tadfisher]

The systemd issue in particular is something I've experienced. nixpkgs does not split systemd into many packages, so everything that needs udev, libsystemd, etc depends on it, so replacing systemd via an overlay will cause a mass rebuild. The trick is to patch systemd and refer to your patched version separately, e.g. with a pkgs.writeShellScript that calls ${systemd-patched}/bin/patched-binary.