ludo@gnu.org (Ludovic Courtès) skribis:

> The grafting mechanism has a shortcoming: it is not recursive.
>
> Suppose we use ‘replace’ to provide a patch libpng.  If a package has a
> direct dependency on libpng, it is appropriately grafted to refer to the
> new libpng.  However, if a package depends on libfoo, which in turn
> depends on libpng, then that package will keep referring to the old
> libfoo, which refers to the old libpng.

The ‘wip-recursive-grafts’ branch fixes that.  It also changes
‘graft-derivation’ to choose whether to graft something based on its
*run-time* dependencies (as reported by ‘guix gc -R’) instead of its
compile-time dependencies.

The advantage is that fewer things will be grafted; the disadvantage is
that things like --dry-run will seem to have no effect since sometimes,
the thing will start by building/downloading stuff.  I think the
advantage outweighs the disadvantage, but we’ll see how it goes in
practice.

There’s room for optimization in a few places, but overall it performs
well and there’s no performance regression in the absence of grafts
AFAICS.  So I think I may merge it real soon, possibly so we can use it
for the OpenSSL fix tomorrow and crash-test it.  Thoughts?

Here’s a patch I used to test grafting (it artificially adds a
‘replacement’ for OpenSSL that is slightly different and yields a
different derivation):