Yes, this is exactly what replaceDependency is for. On Sun, Sep 28, 2014 at 02:58:03PM -0700, [email protected] wrote: > We already have shlevy's "replaceDependency" which, IMHO, solves this > problem. > > In functional programming when we have an immutable tree structure that we > want to update, we trace a path from the root of the tree to the node that > we want to update and we update all the nodes along that path to point to a > newly created "spine" and we get a new tree that shares all unchanged > subtrees with with the old tree. > > shlevy's replaceDependency, and his related NixOS module > system.replaceRuntimeDependencies, works in the same way. Starting from the > root derivation, typically your NixOS system, but could be your > user-enviroment, we can traverse the entire tree of runtime dependencies and > replace one package, say bash, with another package. Then we replace all > the nodes between those adjusted subpackages and the root package with new > nodes that are identical to the old nodes except they have their references > updated to point to the new nodes. These new nodes are created by > derivations that use the old node binaries as "source files" and run sed to > replace the /nix/store/references. > > The result is a new NixOS sytem/user-environment that references the > replacement package everywhere and this all done in a purely functional > manner. > > While this process isn't quite as fast as our mutable cousin's procedure of > updating packages in place in a matter of seconds, this replaceDependency > tree update process can be done in a few minutes without any extenstions to > Nix. For me, I think building bash took more time than replaceDependecy > process and it is certainly faster than the hours or days it will take to > rebuild the whole system. > > On Sun, 28 Sep 2014, Lluís Batlle i Rossell wrote: > > >Hello! > > > >It could be nice if we had a nix derivation attribute that allowed the > >determination of a store path, overriding the hash mechanisms for it. > > > >Imagine that we have a bash to fix; we could add a line in the bash > >derivation > >attribute set: > > forceOut = "whatever store path out" > > > >It'd be nice if nix tools allowed to list (or mark specially on screen) > >derivations that have forceOut paths. It should be applied only in case of > >security fixes. > > > >An operation like "nix-store --repair" should, then, allow for a global > >system > >update. > > > >Another approach, non intrusive to nixpkgs, would be to allow nix to read > >such a > >list of hash overrides (hash → desiredHash) from nix.conf or so. It'd allow > >for > >anyone who cares to get some protection without waiting hydra. > > > >Of course this makes sense for elf programs or shared objects, and not for > >static libs. And hydra should not be using this trick. :) > > > >What do you think? Maybe all this even exists already. :) > > > >Regards, > >Lluís. > >_______________________________________________ > >nix-dev mailing list > >[email protected] > >http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- > Russell O'Connor <http://r6.ca/> > ``All talk about `theft,''' the general counsel of the American Graphophone > Company wrote, ``is the merest claptrap, for there exists no property in > ideas musical, literary or artistic, except as defined by statute.''
> _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
