Hi, On second thought, honouring search paths of dependencies (filtered by looking at the references?) would solve much more problems than it could create -- a theoretical ‘problem’ is that more environment variables than strictly needed might be defined (see e.g. the wrap-program example) but it doesn't seem that it would create problems in practice.
There's a limitation to keep in mind though: static libraries. Suppose we have a static library variant curl/static tht links against openssl:static. Then due to the static linking, curl won't keep a reference to openssl:static (*), so there won't be a SSL_CERT_DIR/FILE search path. (*) Actually, that might wrong, libcrypto.a keeps a reference to /gnu/store/plr00nij45964cyy7sfcg5rcsi8hks0h-openssl-1.1.1l. For some examples in the wild where this kind of propagation(*) of search paths is useful: all packages using ncurses (TERMINFO_DIRS), openssl (SSL_CERT_DIR/SSL_CERT_FILE), all packages using glibc (GUIX_LOCPATH) -- basically all software(!). (*) it's not propagated-inputs but the concept doesn't seem completely unlike. As such, I agree with the concept (notwithstanding the previous mail I sent), with the caveat that I haven't investigated the implementation or tested it. Greetings, Maxime
signature.asc
Description: This is a digitally signed message part
