bug#22138: Search paths of dependencies are not honored

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]