unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Julien Lepiller <julien@lepiller.eu>
Cc: 22138@debbugs.gnu.org
Subject: bug#22138: Search paths of dependencies are not honored
Date: Mon, 05 Aug 2019 12:23:55 -0400	[thread overview]
Message-ID: <87ftmfa8cp.fsf@netris.org> (raw)
In-Reply-To: <20190801221206.17965136@sybil.lepiller.eu> (Julien Lepiller's message of "Thu, 1 Aug 2019 22:12:06 +0200")

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

> Hi, I've been looking at our current code and would like to propose the
> attached patch for that issue.
>
> From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller <julien@lepiller.eu>
> Date: Thu, 1 Aug 2019 22:09:38 +0200
> Subject: [PATCH] guix: Recursively honor search paths of dependencies.
>
> * 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 search
> 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,
XDG_CONFIG_DIRS, XCURSOR_PATH, DICPATH, and GST_PLUGIN_PATH are all set
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

  reply	other threads:[~2019-08-05 16:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  9:36 bug#22138: Search paths of dependencies are not honored Ludovic Courtès
2019-08-01 20:12 ` Julien Lepiller
2019-08-05 16:23   ` Mark H Weaver [this message]
2019-08-05 16:31     ` Julien Lepiller
2019-08-23 14:42     ` Ludovic Courtès
2019-08-24 13:52       ` Ludovic Courtès
2019-11-26 12:00 ` Julien Lepiller
2022-01-14 19:48 ` bug#22138: Should search paths of dependencies be honored automatically? Maxime Devos
2022-01-22 21:27 ` bug#22138: Search paths of dependencies are not honored Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ftmfa8cp.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=22138@debbugs.gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).