From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id oLlaD24v0GKnKQEAbAwnHQ (envelope-from ) for ; Thu, 14 Jul 2022 16:59:58 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KOT0DW4v0GJ1hwAAG6o9tA (envelope-from ) for ; Thu, 14 Jul 2022 16:59:58 +0200 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 BE432C15A for ; Thu, 14 Jul 2022 16:59:57 +0200 (CEST) Received: from localhost ([::1]:54096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oC0Jo-0004hk-Vv for larch@yhetil.org; Thu, 14 Jul 2022 10:59:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oC0JZ-0004gb-7p for guix-devel@gnu.org; Thu, 14 Jul 2022 10:59:41 -0400 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]:42587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oC0JX-0007GG-Dt for guix-devel@gnu.org; Thu, 14 Jul 2022 10:59:40 -0400 Received: by mail-ej1-x643.google.com with SMTP id sz17so3887342ejc.9 for ; Thu, 14 Jul 2022 07:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=mQFOkQyBson4ShkseGHvuxU5XiLSf9RopU9XYbBRwm4=; b=B+BD6wZG2wpvKrPmH+z9q/hQvN4I/0Er0XN3O8fZgazbj6ywiuV9uNVdDXqZNwAjW0 BrVeipbThBaakZURKOKfiDd97s8Ndu80kzBuk7roZNdLPcNgA1wmoyVZtQGyUO+0Mm7A N9laBtLRM6EGEN40kAkF3gXrszE6QQWpQfGQYzWO3YASsMtL/xIcMUT7SErsN8EzYfnZ MdwHNmFNaFPpIxXMTKSrHEsFpSqtubt+JJTCAJKByTAqvhivy9I/luXHxbpvxj0SUh2e koDnx3Yn+HZBskRKEWHela1LVwrhZ2DKKoiWF3a+48CwjFCMqS2lu4wBNbvGMQpCFTLc Rc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=mQFOkQyBson4ShkseGHvuxU5XiLSf9RopU9XYbBRwm4=; b=mN9G9BuMDDw9Rag4kYXsCgv25FsTZQOCRxR6+gwN5/3SbGm2nWL+9v4TH8TGhO9/8a 6E7ydy5XaD76cqGIlSOTCGGarL1bXGtgShLs8Cms2CQ2q6khCfup1ntS+eqaaetlA82E LX3JJtdomuJS9ZtAIGTz6QtkaSLdllium8NyDO4hpSq3rG9EovIt73r1qxVvxX1AhI0C hPkpCDqaafdrKqTzohF5U1FMSgQlGmTNDMshzuwVF2GsxbtL++5TPh1sE9uSmzQLh80e Gu2uHyLSmYxLOe9VV2o9r2dNeSCoRC7HTcpNa49LMJu6NYK0XaqgV43YGzCpEd7wiRub lELA== X-Gm-Message-State: AJIora/KgCqmvH+yfdzfe30g99o0UtFxwa3v7QD/+b2SDilmIrlemMZR m4myIueujkK4jk13Ubv0Cjc= X-Google-Smtp-Source: AGRyM1uBtGP/+lQGyE4aIUT6bv3FwqzRTKTFIWrY6kxb+ooSVctgax8SzGs00A5/Nc/aiX/ro7rK5g== X-Received: by 2002:a17:907:94cf:b0:726:c81a:f30e with SMTP id dn15-20020a17090794cf00b00726c81af30emr9148183ejc.451.1657810777973; Thu, 14 Jul 2022 07:59:37 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id h14-20020a17090619ce00b0072b4da1ed9asm775345ejd.225.2022.07.14.07.59.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jul 2022 07:59:37 -0700 (PDT) Message-ID: <47c56b0d58dbcf4d48b5a4a6bc70d9955cb86a91.camel@gmail.com> Subject: Re: [WIP Patch] Adding an FHS container to guix shell From: Liliana Marie Prikler To: John Kehayias , "guix-devel@gnu.org" Date: Thu, 14 Jul 2022 16:59:36 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::643; envelope-from=liliana.prikler@gmail.com; helo=mail-ej1-x643.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1657810798; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=mQFOkQyBson4ShkseGHvuxU5XiLSf9RopU9XYbBRwm4=; b=YJOUXGJjDLE8eEAXxBlyyMaEQKc4GC303c7DKiv6wAIZ1F+of1I+hTOIWvv+UdYEWYHeer bf8dCFSRgVSMlnD46QZTlJGSLplrMjQzAdCx99WTAUfQj3sIfEa8VXtaCSuD7oEg/7peCb NDZ/+2PNZAHpAqz03h0EsN7cRcWW5AjKkkm2qET3P3cEttTGEij2gpsAJDcscLZa8KA7lx ktOEXWPEg449AanLPUzWVBbmOyK/AHilqs4fMn37BMpYHntSBuqghVkg2sINRyQd2ms46I LTvVGOM73+0zDB3TSWslGHk2M48X2HB+uL8UIygCPLOQEM1tT6lB3itxC4Vrlw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1657810798; a=rsa-sha256; cv=none; b=DY85I5SrLuP+3v7+7MjuNx/7VgA9tl0GmnzyhmLNStHww++Lhu71R89T2DGlk+EpRKqXbT cA+fv2veewOyMjhnJQKiwtRHGarZ4VfhmHn9eN9VT3iL/9WDMopqHAQUuHpr3iFhdCv32P RYhBGuCDZ6H1UoqzlubzyU5woXrnPH+dEEzwWLEYMOw/gYWA6amLsASoDg4c3lCeCiRxTt uM9zaXe9MKAw98tiw3nd/+BsJEEBTgIqvMXF3xRQv3Twl+r7U90dV4QU6Z8tEprgH2p4Z1 fEsMyx0CsEYu7FMVN18qcxL9wnrKpYCX9nAR/XWicj+Aam3o9iLeY/zI+gsLXQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=B+BD6wZG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.05 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=B+BD6wZG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: BE432C15A X-Spam-Score: -5.05 X-Migadu-Scanner: scn0.migadu.com X-TUID: QXyCec/WiISX Hi John, Am Dienstag, dem 12.07.2022 um 15:59 +0000 schrieb John Kehayias: > Hi Guixers, > > Apologies for the long email, so let me start with the punchline: > attached is a diff which adds an '--fhs-container' (or -F) option to > guix shell/environment to set up an FHS-like container. This includes > the usual /lib directory and a glibc which loads (a generated in the > container) /etc/ld.so.cache. This should allow running most things > that expect a more "typical" Linux environment. Give it a try! > > First, I wanted to ask how people feel about such a feature. > Obviously, one use is to run pre-built binaries (isolated!), but this > is also handy for setting up development environments when not able > (or wanting) to with Guix packages only. For example, using the > rustup [0] scripts, pretty much anything JS, or just following > typical Readme instructions to try out something new before > packaging. I won't debate the details here other than to say this > topic comes up with Guix and I think it is yet another useful tool > for guix shell and containers. > > Nix, which I know almost nothing about, does have some FHS > container/environment options as well. > > Next, some technical points about implementation, which I hope will > be informed by the first question and what we want from this tool. > There are two main things needed for the FHS-container: > > 1. Set up directories like /lib. This is easy enough and can be done > currently, like in roptat's response here [1] by building the profile > first to know where to link to. Note that it is easier to do it > within the environment code since we have access to the profile even > if it is being built for the first time. There are some wrinkles with > linking something like /bin since we currently add a link for sh; see > the comments in my diff. > > Right now I did not handle a multi-arch setup, though that shouldn't > be too difficult. This would probably require an option to build > either all or specified packages for an additional arch, like 32bit > in a 64bit system, and make the libraries available (/lib32 or > something). Though may run into a union-build bug [2]? > > 2. Typically binaries will expect the ld loader to use > /etc/ld.so.cache for finding libraries. So, I made a glibc package > that removes our dl cache patch to restore this behavior. It seems > enough to add this as a default package to the container, though I > commented out an option to automatically graft everything with this > glibc. Both worked for me, but grafting didn't seem necessary. Would it make sense to keep our libc, but also symlink the cache to its FHS place? Or do we need to patch our libc so that this cache is tried if a Guix-specific one isn't found? > The second step is to generate the ld cache, which is done with a > simple startup script in the container, after creating a temporary > ld.so.conf (our ldconfig doesn't use the usual default directories?). > I'm sure I found the hackiest way to do this, but it works :) Again, > this could be possible without modifying guix containers, but this is > easier. (For example, you can see work done by myself and others at a > certain non-free channel to do exactly this.) > > Some questions going forward, besides overall cleanup and tweaking of > the code (which I provided comments in for some details, please see > there). It might be nice to be able to extend containers more easily > with setup scripts, though again this can be done by making some > Guile scripts to wrap a container and making a package around that > (e.g. from the non-free channel). What kind of extensions would be > useful to expose? I think I saw some talk on IRC recently about how > to manage env variables when using guix shell. Perhaps an extended > manifest format for shell? > > Relatedly and more generally, perhaps it would be good to have > somewhere (cookbook?) some recipes of useful guix shell container > incantations. Sharing what you need from the host for graphical > programs can be a little tricky to figure out. We have the --network > option, maybe others would be useful? Or some base package lists for > development: just like we have our various -build-system's, a package > list with typical library sets might be a nice convenience. > > What about other uses for this container, like providing an isolated > environment to build and run software we can't do fully with > bootstrap and sources (like JS)? Could this become some stop-gap to > allow people to work with these ecosystems in a more controlled way > within Guix? Or an alternative build environment? Not entirely sure > what this could mean, just thinking out loud. I don't think we should rely on FHS containers in the build system. It's nice to have such a feature as a user, who really needs $ELECTRON_APP and doesn't care about the fact that it's a packaging nightmare, but on a system level, we ought to provide abstractions that are meaningful and helpful to *everyone*, and FHS containers increase both the complexity and the failure potential. See also antioxidant- build-system as an example for making Rust packaging sane (we'll likely need a similar effort for JS). > [...] > +;;; Copyright © 2021 John Kehayias Is this the right year? > + -F, --fhs-container run command within an isolated FHS > container")) Rather than adding "--fhs-container" as an alternative to --container, I'd like something like "--emulate-fhs", which as the "--networking" option is to be *combined* with -C. This makes the interface more symmetric. > + (symlink lib-dir "/lib64") > + (symlink lib-dir "/lib") You'll probably want to split 32-bit libraries (if any) and 64-bit ones here. Also, bear in mind that certain architectures are 32-bit only. Cheers