> Let's say that A depends on B, and B depends on C.
>
> With search paths, A doesn't have symlinks to B, and B doesn't have symlinks
> to
> C. Thus, disk space is saved.
>
> However, adding search path patches to existing softwares is cumbersome, and
> a
> long list of search paths results in inefficient searches.
>
> Let's assume that B has symlinks to C, and A has symlinks to everything in B.
> This means A has symlinks to symlinks in B. Transitive symlink is probably
> more
> efficient than search path. If A just copies symlinks from B and has symlinks
> to plain files in B, then A ends up with only direct symlinks. Direct
> symlinks
> are more efficient than transitive symlinks.
>
> It seems that search paths are preferred over symlinks to transitive
> dependencies in gnu guix. Why?
Search paths are preferred because their purpose is to provide a list of places
to look for extensions/plugins/mods of a package. Essentially, search paths are
a way to provide runtime dependencies that are optional.
Packages usually link directly to their dependencies at compile time, except
for scripting programming languages(which aren't expected to have linking
functionality). Propagated inputs are used for the transitive dependencies you
mention, but they should only be used for required dependencies that have to be
installed with the package for it to detect them.
Packages shouldn't need to have symlinks in their output to another package
when it could just directly reference it instead. More information on how
native-inputs, inputs and propagated-inputs are different is explained in the
Guix manual:
https://guix.gnu.org/manual/devel/en/html_node/package-Reference.html#index-inputs_002c-of-packages
