Hi Ludo, Hi Ivan, @Ludo: Could you take a look at patch 1? It's allowing the lookup of transitive dependencies in Guix to be more flexible. Is it OK? It's used in patch 2 in order to consider both inputs and propagated inputs rather than just propagated inputs. @Ivan: Thanks! I've tested it and it works. But I don't understand yet why you change the role of "inputs" compared to how it is in the rest of Guix. You have this: +(define-public rust-proc-macro2 + (package [...] + (build-system cargo-build-system) + (native-inputs + `(("rust-quote" ,rust-quote "src"))) + (inputs + `(("rust-unicode-xid" ,rust-unicode-xid "src"))) [...] Here, inputs refer to SOURCE parts of packages which are definitely not referred to at runtime. Does "guix gc --references ...rust-proc-macro2..." really refer to the source of rust-unicode-xid ? I checked, it doesn't, neither for the "src" derivation nor for the "out" derivation. I think the general approach is good but I'm not certain that this won't break other parts of Guix. If it doesn't, fine. @Ludo: WDYT? Details: A Rust crate has dependencies and dev-dependencies. The crate needs the dev-dependencies only when building, not at runtime. Let "transitives of X" mean "X and transitives of immediate dependencies of X and transitives of immediate dev-dependencies of X", recursively. The crate needs the source code of all its transitives to be available when building, but needs none of the source code at runtime. A crate at run time only requires the immediate, if even that (probably not!), dependencies and none of the dev-dependencies, and not as source code. So it's really not a propagated-input, although it kinda seems like a weird version of a propagated-input while building (something like a native-propagated-input). If this can't be generalized (and I'm not sure of that--Go has a similar static library-y view), we could also do those as (arguments ...) for the rust build system only--although not sure how to do the resolving of transitives then.