Yeah, but I get what you're saying: Poking our own hole into the store
would set a bad precedent. And disk space is cheap (except on hydra ;-)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
2016-02-17 18:46 GMT+01:00 Shea Levy :
> Details are at
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/replace-dependency.nix,
> but basically yes it goes into all dependents and copies them over to a new
> output with references updated, based on the same
There is a much better solution available to entirely replace a bad
store path without violating any nix invariants (e.g. modifying store
paths), see
http://lists.science.uu.nl/pipermail/nix-dev/2016-February/019564.html
for an example. It does have the same dynamic-only limitation, of
s/for glibc in/for glib in/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
To fix the horrendous glibc bug [1] on my system, without rebuilding my
whole system, I just rebuilt glibc with the fix from master. Then i just
softlinked older versions of glibc-2.21 to the fixed one, by doing the
following in a zsh:
# uses zsh/files to be able to use mv and ls
# while glib is