Hi Leo, Leo Famulari <l...@famulari.name> writes:
> 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. I disagree that grafts are a violation of the functional packaging model. The only violations of the functional package model that I'm aware of are cases where packages fail to build deterministically. In other words, if a set of packages build deterministically, i.e. if the process to build them is a mathematical function, then it will still be a mathematical function when grafts are added. However, one potential issue with grafting is that packages are _built_ against the original (buggy) packages, and then store references to those buggy packages are later replaced (via copying, not mutation) with references to their replacements. In some cases, that might not have the same result as building against the replacements to begin with. So, it's still a mathematical function (assuming all packages build deterministically), but not necessarily the same function as if normal upgrades had been done instead of grafts. That's the main issue with grafts that I'm aware of. One particular case where there's a difference is if there are any references to grafted packages in build outputs that the reference scanner is unable to find, e.g. references within compressed files, or references encoded in UTF-16. Even without grafts, these hidden references can be a problem, because if *all* references to a dependency are invisible to the reference scanner, then the dependency could be deleted by the garbage collector, leaving those references dangling. With grafts, the problem of these hidden references becomes far more severe, because the hidden references will not be rewritten by the grafting process, and thus references to packages with security flaws could remain and be used at run time. This is not a violation of the functional packaging model, though. Does that make sense? Regards, Mark