From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 14:49:07 2022 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: Subject: Should search paths of dependencies be honored automatically? From: Maxime Devos To: 22138@debbugs.gnu.org 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-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22138 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-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/--