On Mon, Dec 14, 2020 at 11:32:05AM +0100, zimoun wrote: > But if grafts is here, it is because of something. Therefore, I do not > understand what it does mean “ungraft”. Avoid the grafting mechanism > when it is possible?
Grafts are used to "hack" the package dependency graph. We try to make some change in the dependency graph without having to recompile everything as normal. When we say "ungraft", we mean that we want to effect the same change in the dependency graph, but without using a graft. For example, if there was an urgent security update of OpenSSL to version 42, we would create a new package 'openssl-42' and add (replacement openssl-42) to the primary 'openssl' package. To ungraft, we'd remove the (replacement openssl-42) field from the 'openssl' package, and simply update the 'openssl' package to version 42. Does that make sense? Before Guix had a recursive grafting mechanism, we had to deploy urgent security updates by rebuilding everything. We either had to wait for everything to be rebuilt, which might take too long, or make users rebuild everything themselves, which could also take too long, and might not work at all on some computers. When we added the recursive grafting feature, we intended to use it to deploy urgent security updates quickly, but we also intended to "ungraft" quickly, maybe in a week or two. We never planned to keep packages grafted for several months as we do now — grafts were considered a necessary but unfortunate violation of the functional packaging model.
