Re: New “ungrafting” branch

[Mark H Weaver]

Hi Leo,

Leo Famulari <leo@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