Guillaume Bouchard d1b6d2d0ab haskellPackages.callHackage: updating all-cabal-hashes do not invalidate callHackage ... Packages built with `haskellPackages.callHackage` won't be rebuilt when updating `all-cabal-hashes`. The removed comment was keeping a reference to the `cabal2nix` call, which itself depends on `all-cabal-hashes`, in order to keep this file during a garbage collection. The tradeoff is between: - The current behavior: a mass rebuild, any change of `all-cabal-hashes` triggers a rebuild of all the packages built with `callHackage` and packages which depend on them. This can take hours, and may happen after a "small" unrelated change (i.e. an user is bumping `all-cabal-hashes` in order to use a new package from hackage). It also have global impacts in a project (long rebuild in CI, new entries in cache, developers need to fetch the new entries, ...). In this context, `cabal2nix` entries are not garbage collected. - The new behavior: No mass rebuild, but `cabal2nix` derivations need to be recomputed after a garbage collection. This is usually fast (a few seconds by call), linear with the number of calls and should not happen a lot (i.e. users are not garbage collecting everyday). See https://github.com/NixOS/nixpkgs/issues/194751 for details.		2022-11-26 19:00:56 +01:00
..
manual	haskellPackages.callHackage: updating all-cabal-hashes do not invalidate callHackage	2022-11-26 19:00:56 +01:00
varlistentry-fixer.rb
xmlformat.conf