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 ms5.migadu.com with LMTPS id iNxQNk29dmLaYQAAbAwnHQ (envelope-from ) for ; Sat, 07 May 2022 20:41:17 +0200 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 wD84Nk29dmJr7wAA9RJhRA (envelope-from ) for ; Sat, 07 May 2022 20:41:17 +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 D90462F08D for ; Sat, 7 May 2022 20:41:16 +0200 (CEST) Received: from localhost ([::1]:46074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nnPMh-0004vb-3f for larch@yhetil.org; Sat, 07 May 2022 14:41:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnPMU-0004vO-Ti for guix-patches@gnu.org; Sat, 07 May 2022 14:41:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59048) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nnPMU-0006co-Kv for guix-patches@gnu.org; Sat, 07 May 2022 14:41:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nnPMU-0008I1-H6 for guix-patches@gnu.org; Sat, 07 May 2022 14:41:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55248] [PATCH 1/7] gnu: racket: Update to 8.5. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 07 May 2022 18:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55248 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler , 55248@debbugs.gnu.org, Maxime Devos Received: via spool by 55248-submit@debbugs.gnu.org id=B55248.165194880531788 (code B ref 55248); Sat, 07 May 2022 18:41:02 +0000 Received: (at 55248) by debbugs.gnu.org; 7 May 2022 18:40:05 +0000 Received: from localhost ([127.0.0.1]:52945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nnPLY-0008Ge-Dg for submit@debbugs.gnu.org; Sat, 07 May 2022 14:40:05 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:41547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nnPLV-0008Fz-1k for 55248@debbugs.gnu.org; Sat, 07 May 2022 14:40:03 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9E83432004ED; Sat, 7 May 2022 14:39:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 07 May 2022 14:39:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1651948793; x=1652035193; bh=CjaCK4VMUgfIzifJ/AHhVw+Z9 3paxE1qpp5WYlqSq28=; b=lOEjos11pnjqlr00UiozIf4/abnT2KwAfOXHL1bzL P81XkWI6/JsafqumbMN0V4d/kgNl+kX54jano2S4C6hjXbOR060XVNThf2ubF9SM DWXZlXqM/lbPvDxPtsDfzY6n0K9H1/Xp4Wx8zCR+cQjYnFDKq4LiLHIeNHFq1itY XIzGJtsyDAJT9c2dIBXeA25+PNSJmdIlbf2GT6HaaYzl/7nVuzuUrxnPRuxGGcMN 3RlSqxvsDCWLUxk22UkD0c+kFmkgnEIkKJeq55SX/RUAckARAklv6XmDIJJpRx8H jUG6IPjCsyQbMUpN0MPMwuXO2CwuTRYNvf1LtHLdDKOAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1651948793; x=1652035193; bh=CjaCK4VMUgfIzifJ/AHhVw+Z93pa xE1qpp5WYlqSq28=; b=f2yk4wAnzKX/eSOKofWUG6Vj9mIevm/5IDI2d08yqdHv szpLcMMnl4z0bsLXfDASN+Ew3D46u7/oJy9ATb8BHFFNiXurNQ/sCg7UxFqB5Hp3 OCnPiAcnoP0QTHzr/rjP03HnzFEoOEfc6ngHkU9UKZO/BysXTohJfN0+SDyRRZak Sn2bM1dBfD2WHaFgriIuvm3mcBS3WHgXLLgOEpI5Dmh5Vj+r3aMKREGyUHrDmiD5 L03nYtY3jvKUSOIbf28fa+J3GQNyCEn6OrMy39/rYd8exp5dgTVkyL9z0j/xd+I9 72SjivFYrgoulPMhEaHGGAyDDzLAXR0sNLFHHsJX2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehgdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfhhihhl ihhpucfotgfirhgrthhhuceophhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtoh hmqeenucggtffrrghtthgvrhhnpefgheetkeetheekteehvedugfehledtteeiueffieeu hfegfeeitddtjefgkeeuveenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphesphhhihhl ihhpmhgtghhrrghthhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 7 May 2022 14:39:52 -0400 (EDT) Message-ID: Date: Sat, 7 May 2022 14:39:51 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US References: <2290ebb81a8acaa959eff9f60694330e495e3a19.1651594312.git.philip@philipmcgrath.com> <7b3da393016daa21c35dd27fc086b03339435e9d.camel@ist.tugraz.at> <9d2423b2-aacb-4869-b3a7-e4ac885cc36c@philipmcgrath.com> <03612de279ff26c801eb02a2d0aaa03fecfe59f9.camel@ist.tugraz.at> From: Philip McGrath In-Reply-To: <03612de279ff26c801eb02a2d0aaa03fecfe59f9.camel@ist.tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1651948877; 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: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=CjaCK4VMUgfIzifJ/AHhVw+Z93paxE1qpp5WYlqSq28=; b=vCntrq3rSf3ynD/WOd8x5gsWfbDAH8v6jM+pRMBbK7RsZb3y5vELdaf7TZZLnDS7kMt9Xy BMZGprZoDRWgnCHnYjC2BW/1BYUxg5DHIqesaBVYl2zzlYM3Gwm1E1u6MAdCc3WDImZv1M K1DXfjUldirGnMbApyw0eHPLJCu/6igPIzv09I84YE0NyGxUeNfbSbQ9V1gkZ670rHJ0nV y3QXAZRXOOZqFyUJzBjeIWjRl9SQtO1Dge65ISPYtx/+DUGCF5qc4Xk0bDCTXXt0xnQkEi ZHhrQDe0cpkUudBus7ZDPMtAnjmKM+BUFMSHXX1NryAds6QTXsSf6hzR0e/CWw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651948877; a=rsa-sha256; cv=none; b=D+kdydQst71sK5NLDoE/WxV89deE0IbMP/eeBQ2kYoctzU6028f79PZkQdpOsz0ZsNDkbc PdtivIYIUXaC93tKBxReh2Xm/fURrZZvh4aVnH0KtrJgaScggPviwDG4t5K0h3EsD5FLP+ bqqrNmqLmX28yHM6CO3BoTL2GtNoDPv30hHgGxVMwDxW9/RmVkj8gqWAS0faD4hR1qzzWy Ql2kZq1GRU3HlK+3tqMungYRrDa5jG6O/V2PopKJDFjzs+a6VxjbujCf+e2w/1HtvEDqTT p1g0+euhOe6sPTn+w0flupusTwxJs0i0VuJiXVDoGMlU83+xBNNOG/CHAvx3vg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=lOEjos11; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=f2yk4wAn; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 1.90 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=lOEjos11; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=f2yk4wAn; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: D90462F08D X-Spam-Score: 1.90 X-Migadu-Scanner: scn0.migadu.com X-TUID: LJMPqPPS6q2o Hi, On 5/6/22 02:37, Liliana Marie Prikler wrote: > Hi, > > Am Donnerstag, dem 05.05.2022 um 17:49 -0400 schrieb Philip McGrath: >> Hi, >> >> On 5/4/22 02:53, Liliana Marie Prikler wrote: >>> Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath: >>>> (racket-vm-common-configure-flags): Remove incorrect comment. >>> No.  Unless you address the issue at hand (which I don't want to be >>> a blocker for this series, mind you), it persists.  If you don't >>> like how the comment is written currently, you might suggest an >>> alternative formulation, but people deserve to know that the >>> origtree layout is a hack. >> >> I understand that this is your opinion. I disagree. I don't want to >> make a big deal out of it, but I'm uncomfortable with the fact that >> `git blame` currently attributes to me a statement of opinion which I >> did not write and do not believe. > Well, I'm uncomfortable with the fact that git assigns blame to people. > The wording of the command name is (as many things in git) poorly > chosen, but that's somewhat besides the point. I'm leaving open the > option of writing a comment that you're more comfortable with, but I'm > not leaving the option of silently removing it. > >> I could write a lot of prose arguing in favor of --enable-origtree as >> a matter of opinion, but I'd rather spend my time trying to write a >> racket-build-system, which I expect will make its usefulness more >> obvious. > You can argue in favour of it, but that doesn't change the fact that > this layout breaks assumptions that are held elsewhere. "Dump > everything into a single directory" has never been a good deployment > strategy, and those who use it tend to regret their decision later. > >> For now, I'll limit myself to noting that, while Racket >> supports --enable-unix-style for those who insist on it (a group >> which formerly included me!), if you run the Racket installer script >> [1] with default options, it will install the files that 'racket-vm- >> cs' and similar place in "/opt/racket-vm/" in "/usr/racket". >> Optionally, the installer will then create symlinks is "/usr/bin" >> etc. pointing to a subset of the files that Guix's 'racket-minimal' >> installs into'#$output'. > This paragraph does not make as much sense to another person as you > believe it does. If I'm counting correctly, we're talking about three > different configurations right now. --enable-origtree, --enable-unix- > style, and a default that uses neither of the two. I don't think we > can easily draw inferences from either to the others. > Given the vehemence of your opinion, I was assuming some familiarity with building Racket. There are various ways of ending up with a "Unix-style" installation as implemented by the 'setup/unixstyle-install' module, including `make unix-style` in the top-level directory, `./configure --enable-origtree=no` in the vm source directory, and the default answers to the installer script (which embeds an archive of the built files). There are some platform-specific details, but none that currently affect Guix. (E.g. when building for Mac, you can fine-tune the installation style and the use of GTK vs. Cocoa for `racket/gui`). An in-place installation (as produced by --enable-origtree) is self-contained and can be freely relocated. A Unix-style installation moves parts of an in-place build to better suit a shared FHS prefix (e.g. "etc/config.rktd" -> "etc/racket/config.rktd"; "collects" -> "share/racket/collects"), injects absolute paths to find parts of itself, and generates an uninstall script. But those things are not useful in this context: the `racket` executable from the VM packages should only be run to build the rest of Racket, and we want to build a Racket installation additive, not by mutating it. >> To the extent that there is an assertion of fact embedded in: >> >>>> -      ;; XXX: origtree layout is required by some other packages >>>> down the >>>> -      ;; bootstrap chain.  Remove these flags as soon as we can >>>> do without them. >> >> it is not true. The packages which operate on a Racket installation >> with this layout (e.g. 'distro-build' and 'raco-cross') are not part >> of "the bootstrap chain", and the packages which are part of the >> bootstrap chain do not require --enable-origtree, except to the >> extent that e.g. it is a convenient way of telling apart multiple >> executables named "racket". > From my POV "the bootstrap chain" consists of everything from the first > VM to the final racket package. In that sense, I am sure you > communicated elsewhere that it is very important to get layers going, > and I'm also fairly certain that we can't currently build the VM chain > without origtree either -- at least it would require nontrivial > modification of said packages. > It is true that removing `--enable-origtree` would require nontrivial changes, primarily to `configure-layer.rkt`. > Again, if you have a formulation that is more factual, but doesn't span > several pages like other comments in racket.scm do, you are free to > replace it. I will try to write a strictly factual comment. > However, for the sake of a racket-build-system even, I > suggest that it would be better if racket's own layout was meaningful. > In other words, why can't racket be more like guile and support > RACKET_LOAD_PATH and RACKET_LOAD_COMPILED_PATH? > I mean, you are certainly free to dislike Racket's model of linking and compilation! And, in fact, Racket has enough configuration options and compatibility hooks that you could try to use it with e.g. PLTCOLLECTS, though it would not be recommended, well-tested, or useful for most Racketeers. With the caveat that all analogies are imprecise, why does Guix prefer to avoid relying on LD_LIBRARY_PATH for C libraries? From my perspective, Racket avoids at least several (maybe not all, but we shall see) of the weaknesses/restrictions described in [1]: > This is not the end of stat storms, though. Interpreters and language > run-time systems rely on search paths—GUILE_LOAD_PATH for Guile, > PYTHONPATH for Python, OCAMLPATH for OCaml, etc.—and are equally prone > to stormy application startups. Unlike ELF, they do not have a mechanism > akin to RUNPATH, let alone a run-time search path cache. We have yet to > find ways to address these. -Philip [1]: https://guix.gnu.org/en/blog/2021/taming-the-stat-storm-with-a-loader-cache/