From unknown Sat Aug 09 09:36:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70553: Packages built via gexp but not "installed" are not visible in containerized environments Resent-From: Richard Sent Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 24 Apr 2024 17:41:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 70553 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 70553@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.171398042232716 (code B ref -1); Wed, 24 Apr 2024 17:41:06 +0000 Received: (at submit) by debbugs.gnu.org; 24 Apr 2024 17:40:22 +0000 Received: from localhost ([127.0.0.1]:59583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzgbP-0008US-OA for submit@debbugs.gnu.org; Wed, 24 Apr 2024 13:40:21 -0400 Received: from lists.gnu.org ([2001:470:142::17]:48110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzgbI-0008RZ-E7 for submit@debbugs.gnu.org; Wed, 24 Apr 2024 13:40:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzgan-0001Q1-SJ for bug-guix@gnu.org; Wed, 24 Apr 2024 13:39:39 -0400 Received: from mail-108-mta135.mxroute.com ([136.175.108.135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rzgak-0003x2-3u for bug-guix@gnu.org; Wed, 24 Apr 2024 13:39:36 -0400 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta135.mxroute.com (ZoneMTA) with ESMTPSA id 18f1130df410008ca2.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 24 Apr 2024 17:39:26 +0000 X-Zone-Loop: 47f9e54fe295ad10090592fa85287405d09a9918b4ef X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6CjWQzrlSxQ0P7AQUScyiNSisVEmvaDWeqchPrf4Iw0=; b=CQNw03qdmx5ocnAsy7pqMeP9Z2 gZfEvTkJC9NGRQVmjS4ie1O/h4HUsGXs/kieoW7yQIl+WQ10y5OpeT5JAOicrUIZqnbplLs5qcZqe CtsTOL1gyEegpORHJnQw3jHO9wXTzibKdDUrLPmkSlfkqgOwxL7W6axDRUvCQ4VAkfbZG5P6uMhHP qb84r8M2xG4h1xiON6Pq42P2Lti9H9Vvr30ed7/jSMzUT4kE6itknJL77EF3IaFa2C6buBXq5P/i3 1C5AaEKb+VZBadKSW+LSbotp2AAPsYA+Yvau0YtiGueaLMFFjFEEybMIJTzoRmhiRZ5NrxvoLf0E+ 7437OUPQ==; From: Richard Sent Date: Wed, 24 Apr 2024 13:39:16 -0400 Message-ID: <87mspizmm3.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.135; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta135.mxroute.com X-Spam_score_int: 3 X-Spam_score: 0.3 X-Spam_bar: / X-Spam_report: (0.3 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_TRY_3LD=1.999 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Guix! Consider a home environment with the following configuration: --88--- (use-modules (guix gexp) (gnu home) (gnu home services shells) (gnu services) (gnu packages dns)) Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=richard%40freakingpenguin.com; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 2.0 URI_TRY_3LD "Try it" URI, suspicious hostname 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: -0.1 (/) Hi Guix! Consider a home environment with the following configuration: --8<---------------cut here---------------start------------->8--- (use-modules (guix gexp) (gnu home) (gnu home services shells) (gnu services) (gnu packages dns)) (home-environment ;; (packages `((,isc-bind "utils"))) (services (list (service home-bash-service-type (home-bash-configuration (aliases `(;; Add other aliases here ,@(let ((dig (file-append (gexp-input isc-bind "utils") "/bin/dig"))) `(("wanip" . ,#~(string-append #$dig " @resolver4.opendns.com myip.opendns.com +short")) ("wanip4" . ,#~(string-append #$dig " @resolver4.opendns.com myip.opendns.com +short -4")) ("wanip6" . ,#~(string-append #$dig " @resolver1.ipv6-sandbox.opendns.com AAAA myip.opendns.com +short -6"))))))))))) --8<---------------cut here---------------end--------------->8--- When starting a container with this home environment via `$ guix home container home.scm`, `wanip` will be successfully aliased to `/gnu/store/...-bind--utils/bin/dig` and that package will be built by the daemon. However, because the container only sees a subset of /gnu/store that contains packages registered in the profile, that path will not be present in the container. This can be confirmed by uncommenting the (packages) field. I don't know the best way to resolve this, but in my opinion the fact that Guix lets you combine package "installation" and usage in a gexp is a great feature. This is definitely cleaner than needing to create an entire custom service that extends both the home profile service and home bash service. Especially if this is done multiple times. I also think this is better than adding isc-bind to the profile and hardcoding "dig" in .bashrc. It would be nice if Guix was smart enough to register that store path as belonging to the home environment and keep it visible to the container so the behavior could be consistent between `$ guix home reconfigure` and `$ guix home container`. Perhaps there's a better way to determine the /gnu/store subset that should be visible to containers besides just reading the environmnet's profile. I expect this crops up in a lot more places than just home environments and home bash service. I'd hope for a more generalized solution that solves this problem across multiple services, not specifically home-bash-service. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.