From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 WPLpKq+P0WLZAwAAbAwnHQ (envelope-from ) for ; Fri, 15 Jul 2022 18:02:55 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id GEiYKq+P0WLRsgAAauVa8A (envelope-from ) for ; Fri, 15 Jul 2022 18:02:55 +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 4C04CA984 for ; Fri, 15 Jul 2022 18:02:55 +0200 (CEST) Received: from localhost ([::1]:55468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCNmG-0006eG-HO for larch@yhetil.org; Fri, 15 Jul 2022 12:02:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCNjp-0006D4-35 for guix-devel@gnu.org; Fri, 15 Jul 2022 12:00:22 -0400 Received: from mail-40134.protonmail.ch ([185.70.40.134]:35356) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCNjm-00055j-BW for guix-devel@gnu.org; Fri, 15 Jul 2022 12:00:20 -0400 Date: Fri, 15 Jul 2022 16:00:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1657900815; x=1658160015; bh=t+19okBd+9Ftep1BbSKEgkKs+1hJph71nxjlpPhSRd8=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=gRSSW7TyowDOwM0W+AfaKfH+L13btlHy7Ak3KzhCu+WmhMvfymRyA1sRfKS1gP3Zw DJ0d6NIZp3u2MRFIUnr9J88v8/ZYUSdQkUYQYXW4IFaFZbsXnZkxR28CcqDEw/wcVy 1ZQKUC1vS7MDVLkPQVvlB0cBFcOVn1vrhXC/rQI8eqkTXtYZqRLe3nNCOmSQCZFdeD lZOYb143cJxfGqdzMvadD763aRrt3GrwZckcGiAE4MI+rAgaOgRfiVZvTrtN9i+bkR OQuOdmz+PrpFldYCV/CDB3U9xm5Docgyp5jienuBb+Xv5z79BTUOhfsqe7Y/HIaEfP ej+WhTSYwG7hw== To: Liliana Marie Prikler From: John Kehayias Cc: "guix-devel@gnu.org" Subject: Re: [WIP Patch] Adding an FHS container to guix shell Message-ID: In-Reply-To: <47c56b0d58dbcf4d48b5a4a6bc70d9955cb86a91.camel@gmail.com> References: <47c56b0d58dbcf4d48b5a4a6bc70d9955cb86a91.camel@gmail.com> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.134; envelope-from=john.kehayias@protonmail.com; helo=mail-40134.protonmail.ch 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, SPF_HELO_PASS=-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: , Reply-To: John Kehayias 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=1657900975; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=t+19okBd+9Ftep1BbSKEgkKs+1hJph71nxjlpPhSRd8=; b=hoPx4ZcEKj9EBHyDWU+z6HRV4nk56Y5WT5fhOf2sugoKD5NpBPBVF7XufZwUTc5Ls27Sc6 bcN7oVG+NXlXgiwpTdjDKADKOP3jkAXjNl/KbgkjWq2e77KPTNACQJ5JI6yBc7su/QjEbg EfJQOrF92smFZLU5r4a0BtTUB6igjnSyMwJGUTx3eEue8AMt0b6QfnUXk3JsYzA4GY4ScY cuLFSUxSUg2lFTb+z9HjtH4ybqPGMRbAW/FqLLUxVXFEVyyErUow4FfG5UcEWIuND8tNwR EaOccUZdxyQ6Fj1fE5Ms5DZQbJN9cm/m024HzcWjSsAo+oEcbeHlBr6rbv1ayQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1657900975; a=rsa-sha256; cv=none; b=YaUdnznaoUrupRQkXCvjfEw0UMNHghIGP3hZA4e13HryhFC+ubXj3uLuuqpqcLAraSewxI cUIicCu9sp133MfiDjeBkswjDWCtYRuI/PEtVnWIMYS3JW95DBr2U4L2eXgrvzyav86DFn AIpAl3SCfcF62xyp269EXN4aU/qPRX5bUBx98NJWy5rhnT9p5QZC2nr6B9u3p6QAqY2SpV 6ggd1IKkpfBtGuwbW9mAgUYsVDeO1QrmUqvcX5CoktjZQejcHQkMC6IksurfuZwR6pxYxd 47mVN59AKafIclPxRGUnqjZgL9M8KIEq3Suc6B2L4U6NwitnwL4C28TwPCOiMA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=gRSSW7Ty; dmarc=pass (policy=quarantine) header.from=protonmail.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: -3.94 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=gRSSW7Ty; dmarc=pass (policy=quarantine) header.from=protonmail.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: 4C04CA984 X-Spam-Score: -3.94 X-Migadu-Scanner: scn1.migadu.com X-TUID: HAtlDhu9gv1Y Hi Liliana, On Thursday, July 14th, 2022 at 10:59 AM, Liliana Marie Prikler wrote: > > > Hi John, > > Am Dienstag, dem 12.07.2022 um 15:59 +0000 schrieb John Kehayias: > (snip) > > 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? > I think it may be possible, but I wasn't able to do this exactly in my effo= rts for a certain non-free package. So I don't remember the details exactly= , but roughly I think it is that our libc will look based on $ORIGIN into a= /gnu/store/.... location for an ld cache. I tried to make this happen with= some symlinking in the container, but it didn't work for me (maybe just du= e to the complexity of the binary I was trying this with?). The general iss= ue might just be making this adaptable if it could work. But admittedly I w= as doing a lot of guessing and learning, so maybe I just wasn't approaching= this correctly. And then removing one patch was just too easy :) As for patching libc so that it falls back to something like /etc/ld.so.cac= he, I would worry about undesired behavior on a foreign distro. Though we c= ould have it look at some other location that wouldn't conflict (some speci= al directory for Guix?). Still, this sounds like it would add complexity an= d difficult to diagnose behavior. Seems cleaner to me to distinguish the li= bc in the FHS container explicitly. Still, I'm open to hear how this could work, just saying I wasn't able to f= igure it out using this approach before. WDYT? (snip) > > 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). > Sure, I agree the main goal here is definitely for the end-user rather than= building. Perhaps there are some applications in some building, but yeah, = didn't have anything in mind. > > [...] > > > +;;; Copyright =C2=A9 2021 John Kehayias john.kehayias@protonmail.com > > Is this the right year? > [checks calendar] it is not. In fact, we're closer to 2023 than 2021 at thi= s point. Thanks for spotting! > > + -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. > Ah, this is a good idea. Then we would enforce that --container is also inc= luded when using the --emulate-fhs option. And the little code I figured ou= t to hijack setting the container option without the user specifying it cou= ld be dropped to make it all more explicit from the command interface as we= ll. I'll do that. > > + (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. > Yes, thanks, I was sort of following what Arch does as my test case. But as= pointed out by Maxim as well, we should keep a generic following of the st= andard. I would like some testing to know if some less standard links are w= idely used though, standards being one thing and what distros do in practic= e another. I'll also leave multiple arch setups for a followup, keeping thi= s first attempt generic. Thanks for the helpful comments! John