From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 2KBnGlWn9WUNGwAAqHPOHw:P1 (envelope-from ) for ; Sat, 16 Mar 2024 15:06:13 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2KBnGlWn9WUNGwAAqHPOHw (envelope-from ) for ; Sat, 16 Mar 2024 15:06:13 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=pelzflorian.de header.s=key2 header.b=DmU3wSOj; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710597973; a=rsa-sha256; cv=none; b=YAsa6OU4vsrs+PomWi1R2YZA6s+A6e4F9ENrjpz7Z8dpiy+dWzyBRrR1DtnfLPeyYXB62N s5iJlJi6CXALXR/Uug6d457TPUQfjq2DEcAop3LOSB8ngH9oh34sKvM/UWgEsRoFBWtj78 D27LmLDbaIMlhtwXkpHS6B07UzP15ksEplulmcyT4t2m9ou8r0WtOsi+mgLGl5HGScoIig EHGc9crR5IGnPMiZ0H/uWbq/yIQLAOzAQ+lwb62jB/a2IqIAd9Feh6emgi1IkpuafgpdfQ Fhrb6+9rPHsWISFkzzvYZXu0LgbhiuKrjPf3MmOaLmE91RTc8Y35rTHdoLd+qQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=pelzflorian.de header.s=key2 header.b=DmU3wSOj; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710597973; h=from:from:sender:sender: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=oL+y26qvil2Xe/JMMMke8i/VHmbPlFsvLZ6fpFat1HM=; b=mCq6um0cdR9vn2HJXw57zyzw2ws3CWNiE2fXvzV7B4hGyeYEUgAo70YZXCm28/CroVBupS EazDUUESenmBzQkSseFmxl7LoedR0OMl/HUCfu0CHgXInuOYegV5iSHLRn484wPZjkuQaf feUCUshi70nNal7j2ci6sAqu2soQ8jNprJ6B4aMXJw6WeEnQhbQV3QMrU61p3R2bjIXpsx loaCFBsDhxQvNYYeEzEFSW1YiVsMPMNb8ZjdBFoLips2dBaRqdVWiF3z8Hk9U+lfZiVhI7 mr0iug2cEt9mdN20F9XOoD21TTOKfZFIk7vY7CTeKx9s5XOH4o+jRyPspEpcvA== 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 D5E55771B4 for ; Sat, 16 Mar 2024 15:06:12 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlUfN-0004Wt-Jg; Sat, 16 Mar 2024 10:05:41 -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 1rlUfK-0004We-4m for guix-devel@gnu.org; Sat, 16 Mar 2024 10:05:38 -0400 Received: from relay.yourmailgateway.de ([188.68.63.98]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rlUf9-0006o2-QH for guix-devel@gnu.org; Sat, 16 Mar 2024 10:05:37 -0400 Received: from mors-relay-2501.netcup.net (localhost [127.0.0.1]) by mors-relay-2501.netcup.net (Postfix) with ESMTPS id 4TxjYv3XRKz62QT; Sat, 16 Mar 2024 15:05:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pelzflorian.de; s=key2; t=1710597923; bh=vEbqDkn1UrJ93neQ63YOGiL+JZiwu3P1WE48aY5XtMw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DmU3wSOjcTjoC9c9HihiXcUJSZsq6b1aeNglE5ruIHc5qyxlD+SQ4Il79/FuC3wv5 dkOhxtbZfPEMG3v3S5Oe0LkKIkXiAgj3sMnpC8Wzq0HbTTIrrNJrmjLF8wWUYapUQ2 buzKI4odJ2HzNWHUEGzHsOpcS1EQHM84+oxM2uFzdIpmVtavxTwUHSIkax6fsdEaTh fHED3rIuTdYG4keQnptCA0aLs+8fLTHpGgOMwmkPPtEfcLMKbLCbG1F6Abanhe8zLl EPivK9olz1/yUei02W8Tu6fZy1qxhjtkSlAt2OagR9zvBFXNEnL84fj81iuQkhSm97 n2mCrP3h3UKmA== Received: from policy02-mors.netcup.net (unknown [46.38.225.35]) by mors-relay-2501.netcup.net (Postfix) with ESMTPS id 4TxjYv2nTZz4yJ6; Sat, 16 Mar 2024 15:05:23 +0100 (CET) Received: from mxe217.netcup.net (unknown [10.243.12.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by policy02-mors.netcup.net (Postfix) with ESMTPS id 4TxjYv02GFz8sgT; Sat, 16 Mar 2024 15:05:22 +0100 (CET) Received: from florianrock64 (ip92344de0.dynamic.kabel-deutschland.de [146.52.77.224]) by mxe217.netcup.net (Postfix) with ESMTPSA id 38C7082DB3; Sat, 16 Mar 2024 15:05:14 +0100 (CET) From: "pelzflorian (Florian Pelz)" To: Matt Cc: "Maxim Cournoyer" , "Christian Miller" , "guix-devel" , "Josselin Poiret" Subject: Re: doc: installation: fix ~root confusion (was Re: doc: Removing much of Binary Installation) In-Reply-To: <18e46e0150a.126718be4584704.7946677375549431621@excalamus.com> (matt@excalamus.com's message of "Sat, 16 Mar 2024 11:47:54 +0100") References: <87a5p8yn4p.fsf@dadoes.de> <18d0e410102.e16898001715108.8020629039859398477@excalamus.com> <878r4ml93e.fsf@gmail.com> <18d23870de2.119d4f41c239950.5543896370981537109@excalamus.com> <18d48373140.10c55a4722276191.1969374822318990762@excalamus.com> <87r0h5ray4.fsf@gmail.com> <18dccf417d0.ca418748214075.562011919630800442@excalamus.com> <87y1bboq2i.fsf@gmail.com> <18dd741c397.eb3e3c20130225.478777462592413812@excalamus.com> <18dff5f7ac0.12981499e295073.4475195706110749663@excalamus.com> <87zfvbgu3q.fsf_-_@pelzflorian.de> <18e154a064f.10b18ae281601105.807357574739020306@excalamus.com> <87bk7qnfd5.fsf@pelzflorian.de> <18e280dc65a.fb9272352515573.111358157668309553@excalamus.com> <87le6ou5ly.fsf@pelzflorian.de> <18e46e0150a.126718be4584704.7946677375549431621@excalamus.com> Date: Sat, 16 Mar 2024 15:05:13 +0100 Message-ID: <87zfuynug6.fsf@pelzflorian.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 38C7082DB3 X-Rspamd-Server: rspamd-worker-8404 X-NC-CID: LyoAWoKKxbad0EvsSrFGpw6DOxy9RP8XbCMth48uMfrjUfA7a9QdekIV Received-SPF: pass client-ip=188.68.63.98; envelope-from=pelzflorian@pelzflorian.de; helo=relay.yourmailgateway.de 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, RCVD_IN_DNSWL_NONE=-0.0001, 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: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -6.20 X-Spam-Score: -6.20 X-Migadu-Queue-Id: D5E55771B4 X-TUID: C7DjFCGDp+pH Hello Matt and thank you for your precise wording. You have made clear the differences: Matt writes: > There are several actions which we have deferred and other topics > which still need to be addressed, such as those raised by Vagrant and > Suhail. My hope is to 1) resolve and merge this immediate patch, as > we appear to be converging on a consensus, 2) discuss how we could > better handle documentation changes than how I've handled them here > (that is, in one ever evolving diff), I think the diff was quite appropriate. You could make a patch via =E2=80= =9Cgit format-patch=E2=80=9D or =E2=80=9Cgit send-email=E2=80=9D, which would incl= ude a commit message and which could include a move of sections 2.2 and 2.3 to the contributing.texi. But it is not necessary for documentation changes. > 3) compile a list of deferred > actions, 4) compile a list of deferred topics, and 5) address points 3 > and 4 according to 2. > > ---- On Mon, 11 Mar 2024 16:54:01 +0100 pelzflorian (Florian Pelz) wrot= e --- >> Yes, however the removal means that we should move the sections >> >> * 2.2 Requirements >> * 2.3 Running the Test Suite >> >> to the Contributing manual in doc/contributing.texi. WDYT? You said, >> it could be a separate discussion, but in my opinion it would be part of >> the same patch. > > I was thinking of the opposite, of moving "Building from Git" into > Installation. What you say makes more sense and I agree. Since the > suggested patch is already quite complex, I have not added moving > Sections 2.2 and 2.3 to the changes. I propose we make the move in a > separate commit. Yes, it should probably be a separate commit, to make it possible to revert it separately. >> > +@cindex foreign distro >> > +@cindex Guix System >> >> =E2=80=9C@cindex Guix System=E2=80=9D is inappropriate, because instruct= ions on Guix >> System are not here. > > Removed. Good catch! > >> > +You can install the Guix package management tool on top of an existing >> > +GNU/Linux or GNU/Hurd system@footnote{Currently only the Linux-libre >> > +kernel is fully supported. [=E2=80=A6] >> >> No. >> >> First of all, using guix-install.sh as per your instructions, one >> installs the Guix distribution *and* package management tool. Either >> say =E2=80=9CYou can install the Guix package management tool and distri= bution=E2=80=9D >> or =E2=80=9CYou can install Guix=E2=80=9D. > > I'm afraid I don't follow. Where do you see the suggested changes > confusing the installation process for Guix as a distribution and Guix > as a package management tool? > > The sentence you quote is the suggested first sentence for the Chapter > 2: Installation. The complete sentence reads, > > "You can install the Guix package management tool on top of an > existing GNU/Linux or GNU/Hurd system(1), referred to as a "foreign > distro", or as a standalone operating system distribution, the "Guix > System"." > > It literally says Guix is a package manager or a distribution. Precisely this terminology is the issue. Nix is a package manager; Nixpkgs is a distribution. For Guix, Guix is both a package manager and distribution. Guix System is not a distribution in this sense; Guix is the distribution. I am aware that some people expect distribution to mean a self-sufficient operating system, but we should not subscribe to one side of terminology. (Actually, the term operating system is complex as well, for example GNU is an operating system and the people from Robot Operating System call ROS an operating system.) I would not address Hurd here at all. Hurd support would be important and is promising, but documentation for it should come after it works on more than a Childhurd. > No > mention of 'guix-install.sh' is made on that page. I wanted to give an example what I mean, not a suggestion. > > The current "introduction" to Chapter 2: Installation is this: > > "Note: We recommend the use of this to > install Guix on top of a running GNU/Linux system, thereafter called a > foreign distro. The script automates the download, installation, and > initial configuration of Guix. It should be run as the root user." > > https://guix.gnu.org/en/manual/devel/en/html_node/Installation.html > > Maybe the diff didn't apply correctly? Maybe it's confusing how the > Texinfo syntax puts the footnote markup in the middle of the source > sentence, even though footnotes render at the bottom of the page? > >> Next, I believe Guix cannot currently be built on existing GNU/Hurd >> systems, because guile-fibers does not work. I do not really know >> enough, but I would not mention Hurd support. > > The are two issues here, what is said and what should be said. > > Regarding what is said, the section we're talking about is for > installing not building. You *can* install the Guix package > management tool on top of an existing GNU/Hurd system. Probably a guix pack of the guix package would run, but Debian=E2=80=99s guile-fibers is not accepted, if I don=E2=80=99t misunderstand. > [=E2=80=A6] >> >> Similarly, IMO the nuances are more appropriate in the old wording >> >> =E2=80=9CFor Debian or a derivative such as Ubuntu,=E2=80=9D rather t= han your change >> >> =E2=80=9CFor Debian and Ubuntu-based systems=E2=80=9D. >> > >> > The current wording is, "If you're running Debian or a derivative such >> > as Ubuntu..." None of the suggested changes include the wording you >> > give. >> > >> > What are the nuances? If they matter, we should probably make them ex= plicit. >> >> The nuance is that Ubuntu is a derivative of Debian. It can be >> bootstrapped with Debian=E2=80=99s dpkg, although I did not follow a rec= ent >> e-mail thread on how to do this from a Guix-provided dpkg. > > Unless there's something about this nuance which directly affects the > installation process, I don't think the distinction warrants mention. > > I opted to ignore the distinction and use "Debian and Ubuntu-based > systems" because many popular distros, such as Ubuntu, Linux Mint, > Zorin OS, Elementary OS, Linux Lite, and Pop!_OS, are known for being > "based on Ubuntu." The relevant information for users of these > systems is not that they're derivatives of Debian, it's that this is > the installation process for such systems. Ubuntu should not get the credits for what Debian is doing. The current wording =E2=80=9CDebian or a derivative such as Ubuntu=E2=80=9D is fairer a= nd equally clear. >> > +@quotation Note >> > +By default, binary installations of Guix build @emph{everything} from >> > +source. This makes each installation and upgrade very expensive. >> > +@xref{On Trusting Binaries} for a discussion of why this is the defau= lt. >> > [=E2=80=A6] >> > - >> > -@quotation Note >> > -If you do not enable substitutes, Guix will end up building >> > -@emph{everything} from source on your machine, making each installati= on >> > -and upgrade very expensive. @xref{On Trusting Binaries}, for a >> > -discussion of reasons why one might want do disable substitutes. >> > @end quotation >> >> Better not change the wording? I believe enabling substitutes is not >> the default. > > My assumption is that the vast majority of readers are not installing > Guix on distros whose default is to compile from source. The concept > and jargon of substitutes, let alone the idea of compiling from > source, is likely completely unknown to most readers. Readers likely > expect, what we would call, substitutes to be enabled. > > As far as I understand, the default behavior is opposite what most > readers would expect: substitutes are *not* enabled by default for > binary installations of Guix. > > The suggested wording avoids the jargon of "substitutes" in favor of > simpler language which directly addresses what the reader likely cares > about: the default Guix behavior is to compile from source which takes > a long time. It also frames the discussion of "On Trusting Binaries" > from the perspective of "the expensive default was decided by careful > consideration." The current wording, "why one might want to disable > substitutes," involves jargon (substitutes) and a negative (disable) > which requires understanding what a substitute is, what the default > is, and whether "disabling" is contrary to the default. That > complexity is unnecessary, as I believe the suggested changes > demonstrate. I just tried now and I had not expected the install script to say: Permit downloading pre-built package binaries from the project's build farms? [Y/n] Getting substitutes unexpectedly is the default (also unlike what you write) and users can complete the installation without knowing the term, but they do get asked. I agree with you now that the wording can be simplified, except it must be rewritten to that disabling substitutes is an option that is not the default. > > I think a valid critique of the suggested changes is "why say 'very > expensive' instead of 'takes a long time'?" The suggestion uses the > phrase "very expensive" instead of "takes a long time" because 1) > "very expensive" is the current language and 2) wall time is only one > of several expenses; others are energy and CPU cycles. This is a > situation where I think it's okay to be non-specific. The point is > "the default behavior may seem undesirable" and the word "expensive" > is typically considered undesirable. I agree that =E2=80=9Cexpensive=E2=80=9D is sufficiently understandable. >> IMHO The discussion about whether Upgrading Guix should recommend to >> edit the systemd service of the Debian guix package is for a >> separate second patch. > > Agreed. Otherwise LGTM. Could you send another diff? Would a commit message like this be okay: doc: Simplify installation instructions. * doc/guix.texi (Installation): Direct readers towards the installation script. Remove superfluous commentary. Regards, Florian