From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YCBbLhzU4WFGjAAAgWs5BA (envelope-from ) for ; Fri, 14 Jan 2022 20:50:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id mIq7KxzU4WHmJAEA9RJhRA (envelope-from ) for ; Fri, 14 Jan 2022 20:50:52 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3552F1EB0E for ; Fri, 14 Jan 2022 20:50:52 +0100 (CET) Received: from localhost ([::1]:56432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8Sb5-00027f-Ar for larch@yhetil.org; Fri, 14 Jan 2022 14:50:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8SaI-00025p-WE for bug-guix@gnu.org; Fri, 14 Jan 2022 14:50:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:45305) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8SaI-0006VF-MO for bug-guix@gnu.org; Fri, 14 Jan 2022 14:50:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8SaI-0003IM-Hq for bug-guix@gnu.org; Fri, 14 Jan 2022 14:50:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#22138: Should search paths of dependencies be honored automatically? References: <87bn9yk5mf.fsf@gnu.org> In-Reply-To: <87bn9yk5mf.fsf@gnu.org> Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 14 Jan 2022 19:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22138 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 22138@debbugs.gnu.org Received: via spool by 22138-submit@debbugs.gnu.org id=B22138.164218974712590 (code B ref 22138); Fri, 14 Jan 2022 19:50:02 +0000 Received: (at 22138) by debbugs.gnu.org; 14 Jan 2022 19:49:07 +0000 Received: from localhost ([127.0.0.1]:38208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8SZO-0003Gy-R6 for submit@debbugs.gnu.org; Fri, 14 Jan 2022 14:49:07 -0500 Received: from michel.telenet-ops.be ([195.130.137.88]:51878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8SZJ-0003GQ-BQ for 22138@debbugs.gnu.org; Fri, 14 Jan 2022 14:49:05 -0500 Received: from [172.20.10.5] ([188.188.180.33]) by michel.telenet-ops.be with bizsmtp id ijoy260080je1N406joyt4; Fri, 14 Jan 2022 20:48:59 +0100 Message-ID: From: Maxime Devos Date: Fri, 14 Jan 2022 19:48:53 +0000 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Kl4tLppGfhUuCV8ziGv/" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1642189739; bh=ygK93bA/5ENRv9kvPpB35kOS8lc6OeWkWjbdQy1hESM=; h=Subject:From:To:Date; b=mPUw5RYiEVv/H1d7MdrxpjIRZ/mt3YTrvg+GChQScGz9ct4hmq04TIBuqOjUyDWMR C2Xy/QxB4OBtxAMhNfNek/mlPAE9cacUtJkMKGqNzIO6zsF+e+f7jwpwzOw2joXShY z3MecBY5s8MGOS+bJFUTRw6ie8ij3eOE0hY1Y8CCmzfZ5dmUplmh5NIcIxP2mmW/EM XM0sKD04zP2nz77FmKeq4llE8G7tZ2SndMoqGqKT/0D6gPvAeFBRo1lnT2EM38pZR5 ONixBNq7Md+Pshxn6iJf4JE2p7RjyhpztLkErJKwaAJVZTc6V4LQQf+jMu+bwitbYd 4IzrmYAfBUCcA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1642189852; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=ygK93bA/5ENRv9kvPpB35kOS8lc6OeWkWjbdQy1hESM=; b=rCa4t4ioj5vuUVY/1P7b7m43o5MRE07BPzA7CCr7UVOoy6mpLMKopI9rvQEpkkVJHXNAXw ewVjyb32hVpBZ+M9AVWBOS5rA/7pU157XJCBzU5N66LwzkFeXtH2OZTHaIxj5nZ8lmSlXS HJuMT1SjCu4zm/cSc4zMBTTEEouXabRI+aK2Tzrieq+FHeNaPxaLZ2T3IYV1JSr6feg4WZ 5Ul0w5xpvt3S+6vIgxg4rBux5V19frrVQCrQ1FWcjq6p11VMqs9UFsBQgvcmlREMuksWS0 pR0KEOKVW4sivGF481aRdwgMtB6Jaxo2akS1XETXuWzs0NuP+VCkvEQ0cNGQCw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642189852; a=rsa-sha256; cv=none; b=C29cMBI0L1Mky35FnYBnEkMDAialgkmVJ5ZmXYfCKv2tlT2ebgJWnY8pcRqQbkoq7RIovu dC7e39XPBwCVHmiXZsiwV6FPMmD8IwogiBNoELkt2m5K+DeuM925q5EUGaUTqwfMj8OA7V KAIjzlKnu6ai5Hzj6VYFj1JmaUXrCSQwiCw7g7YJyNGJDsaxh5UbKQDIhKPOdBlmWCAiL0 Y7Q7O1XJdTfoejyBCiWk6PIKTTxXol+cvC5Pd+YxosfzmIhagHIfdC9u/uN+uBqSLKD3A7 tEALgpBayvlSst391txLPgS8ga7CJwKFclntsJ3K6wdT2zJa8S4+tr29NYQccg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b=mPUw5RYi; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.42 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b=mPUw5RYi; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3552F1EB0E X-Spam-Score: -4.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: D3Khs1KP0hfp --=-Kl4tLppGfhUuCV8ziGv/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (first section) > As of 0.9.0+, only the search paths of packages explicitly in the > profile are shown by =E2=80=98--search-paths=E2=80=99 and similar. This = is a problem > for libraries that have associated environment variables. > > For instance, if one installs an application linked against OpenSSL, > they will not know about =E2=80=98SSL_CERT_DIR=E2=80=99 and =E2=80=98SSL_= CERT_FILE=E2=80=99. Similarly > for GStreamer and =E2=80=98GST_PLUGIN_PATH=E2=80=99, libc and =E2=80=98GU= IX_LOCPATH=E2=80=99, and so on. > [...] > [... stuff about references-graph ...] I want to note that it is possible to use a library in a program without needing the environment variables. E.g.,=C2=A0web servers can use openssl, but often only for listening so they don't need a certificate bundle. A game using GStreamer for sounds knows in advance which plugins it will need, so the package definition would be using 'wrap-program' or the like to hardcode the set of plugins. Many (almost all?) packages keep a reference to the "lib" output of "gcc", but almost no packages need '{,CROSS_}C_INCLUDE_PATH', '{,CROSS_}CPLUS_INCL= UDE_PATH' or '{,CROSS_}LIBRARY_PATH'. That said, adding these superfluos environment variables is probably harmless in practice, but it kind of breaks some abstractions: If I use a package as input that uses a search path and I fix the search pa= th using 'wrap-program' or the like, then I would expect things to be as if th= ere wasn't a search path in the first place, but IIUC the proposed patch lookin= g at references would break things. Also, the patch seems to only affect profiles and not build environments, creating another distance between them, which seems suboptimal. For these reasons, I don't think search paths of dependencies should be hon= oured. However, there are things to improve: (second section) I believe a better option would be to document search paths better in the m= anual (there's almost nothing currently about search paths) and make search paths= easier to use. E.g., we could move =E2=80=98generic=E2=80=99 search paths used by several = packages (e.g. INFOPATH, TERMINFO_DIRS, XDG_DATA_DIRS, GST_PLUGIN_PATH, SSL_CERT_DIR and SSL_CERT_FILE --- why is SSL_CERT_DIR missing from icecat and guile anyway?) (counter-example: MINETEST_MOD_PATH, because it is used by only one package) into a common module next to each other, which some small comm= ents [...] ;; FWIW I think I suggested something like this elsewhere, in the context ;; of module import loops. ;; for info readers (info-reader, emacs, ...) (define-public %info-path ...) ;; for programs interacting with terminal emulators, ;; e.g. almost anything using 'ncurses' (define-public %terminfo-dirs-path ...) ;; for packages using TLS, e.g.=C2=A0web browsers (icecat, ungoogled-chro= mium, ...), ;; e-mail clients (evolution, icedove ...), most software 'openssl' ;; ;; Not all packages using TLS respect one of these two variables. ;; ;; (TODO check if these examples actually respect SSL_CERT_DIR/PATH) (define-public %x509-cert-dir-path ...) (define-public %x509-cert-file-path ...) [...] and mention this module in the documentation of 'search-paths', invite people to look at the source code of the module for examples people maybe even documenting these search paths in the manual. Maybe also insert a reminder about search paths in the 'reviewing' section? I think this (keeping standard search paths together, with some explanation= , with some example packages using these search paths ...) would help discove= rability a lot, reducing the risk that a package is defined without appropriate sear= ch paths. Such a common module would also reduce redunancy (a single definition of %f= oo-path instead of sprinkling it among separate packages) and reduce the chance of = module import loops (maybe we can move the python search path there?), although the latte= r could be solved with thunking (at some cost). It's also possible to do both this (manual documentation, common search pat= h module) and the patch using the reference graph. This ignores GUIX_LOCPATH, but that's used by almost anything, so it could = be special-cased I think? Greetings, Maxime. --=-Kl4tLppGfhUuCV8ziGv/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYeHTpRccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7v+HAQCW39ekw+T8CnedRiOqVHTO/sqW 6ZtJVAs1Z3SROPsSpwEA8haWJBuOCFLVKuNXndpAzsavmxqEU0xnjHcVDbJBTgc= =sClV -----END PGP SIGNATURE----- --=-Kl4tLppGfhUuCV8ziGv/--