[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22138: Search paths of dependencies are not honored

From: Julien Lepiller
Subject: bug#22138: Search paths of dependencies are not honored
Date: Mon, 05 Aug 2019 18:31:15 +0200
User-agent: K-9 Mail for Android

Le 5 août 2019 18:23:55 GMT+02:00, Mark H Weaver <address@hidden> a écrit :
>Hi Julien,
>Julien Lepiller <address@hidden> writes:
>> Hi, I've been looking at our current code and would like to propose
>> attached patch for that issue.
>> From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00
>> From: Julien Lepiller <address@hidden>
>> Date: Thu, 1 Aug 2019 22:09:38 +0200
>> Subject: [PATCH] guix: Recursively honor search paths of
>> * guix/packages.scm (all-transitive-inputs)
>> (package-all-transitive-inputs)
>> (package-all-transitive-native-search-paths): New procedures.
>> * guix/profiles.scm (package->manifest-entry): Use
>> package-all-transitive-native-search-paths to generate manifest
>> paths.
>As I recall this kind of solution has been proposed in the past and
>rejected.  It's a reasonable suggestion, but I personally think that it
>goes too far, because it would include a great many packages whose code
>is nowhere to be found in the resulting profile.  For example, it would
>include documentation generators used to build man pages, and the
>compilers that were used to build those documentation generators, etc,
>all the way back to the early bootstrap binaries.
>Having said this, I agree that there is a longstanding problem in Guix
>with search-paths not including enough packages in its calculation.
>We've known about this problem for a long time, but as far as I know we
>have not yet found a satisfactory solution.
>Our current hacky workaround for problems like this has been to set
>certain environment variables unconditionally in /etc/profile.  For
>example, you'll see that MANPATH, INFOPATH, XDG_DATA_DIRS,
>there.  See 'operating-system-etc-service' in (gnu system) for the
>relevant code.
>At the very least, I think we should wait for input from Ludovic before
>applying anything along these lines.
>Anyway, thanks for looking into it and making the proposal.
>      Best,
>       Mark

Tgis patch doesn't add any dependency to any package, since it doesn't record 
any more stone paths than without. It indeed defines more variables than 
needed, but isn't that ok?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]