I realigned the subject. It was previously changed to "doc: Removing much of Binary Installation" which is misleading. The topic is how to clarify installation based on reported confusion, not about removing text. The reported confusion was on the use of '~root'. Explicit mention of '~root' is only necessary when the manual details how 'guix-install.sh' works. Since 'guix-install.sh' is the recommended method of installation, such level of detail is unnecessary, inappropriate, and impractical. The suggested changes address the issue, only incidentally, by removing text. I respond to Suhail Singh, Vagrant Cascadian, and pelzflorian in order. ---- On Wed, 06 Mar 2024 22:18:33 +0100 Suhail Singh wrote --- > Suhail Singh suhailsingh247@gmail.com> writes: > > > FWIW, as an openSUSE Tumbleweed user, I believe Tumbleweed users who don't care if there is an easy way to uninstall Guix would be better served by using =guix-install.sh= as opposed to =zypper=. > Btw, for completeness, on Tumbleweed, the user needs to take some additional steps to ensure that restoring a previous Tumbleweed snapshot doesn't revert Guix state. Unless I'm misremembering, these steps are needed regardless of whether =zypper= or =guix-install.sh= was used to install Guix. Thank you for this. I want to follow up with Vagrant and Florian first before responding more fully. ---- On Wed, 06 Mar 2024 22:29:23 +0100 Vagrant Cascadian wrote --- > As the one who packaged and maintains guix in Debian... Thank you for doing this work! > The guix-daemon should continue to work from the packaged version, although as guix develops more and more features; how long an old version can be expected to continue to work remains an open question. I was under the impression that Guix installed through a foreign package manager is able to update with 'guix pull'. This is what the current documentation says, "If you’re running Debian or a derivative such as Ubuntu, you can instead install the package (it might be a version older than 0.0-git but you can update it afterwards by running ‘guix pull’):" Is this correct? Does 'guix pull' update Guix when installed through a foreign package manager? ---- On Thu, 07 Mar 2024 18:03:50 +0100 pelzflorian (Florian Pelz) wrote --- > I first tried guix-install.sh on a Debian GNU/Hurd VM. It fails, telling me: > > [1709825168.049]: [ INFO ] init system is: sysv-init > [1709825168.059]: [ FAIL ] Unsupported CPU type: i686-AT386 > > The script guix-install.sh cannot be used on any GNU/Hurd system. Thanks for taking the time to test 'guix-install.sh' on Hurd. This looks like a bug. > Vagrant’s guix package is missing on Debian GNU/Hurd as well, which is fine of course, but we should not claim otherwise. Updated to specify "distributions" as "GNU/Linux distributions". > Therefore, could you change it like the old instructions and only talk about GNU/Linux? I don't think that's appropriate. Guix supports GNU/Linux and GNU/Hurd and the installation section needs to cover both. There are two issues here: 1) Up to this point, the manual doesn't make clear that current GNU/Hurd support is limited I've duplicated the footnote from the 'operating-system Reference' section which explains the current status of GNU/Hurd support: https://guix.gnu.org/en/manual/devel/en/html_node/operating_002dsystem-Reference.html 2) 'guix-install.sh' has a bug preventing installation on GNU/Hurd Any takers? > > If, instead, you want to install the complete GNU operating system, @pxref{System Installation}. > > Maybe better say “complete Guix operating system”? *complete* GNU operating system maybe should only be used for GNU/Hurd. That line is directly copied from the current manual: https://guix.gnu.org/en/manual/en/html_node/Installation.html#FOOT4 I saw this and I agree with you. It would be better stated as something like you suggest. My intent was to do this in a separate patch. > You suggested in your mail: > > Matt matt@excalamus.com> writes: > > Readers interested in those details may read the code for 'guix-install.sh'. > > Could you add this suggestion to your diff? I don't see that as relevant to the reader. The ability to read the source is implicit in it being provided, which it is. > IIRC, you are removing the manual installation. Yes? No? I'm not sure how to respond. The suggested changes remove superfluous commentary on the recommended binary installation process which create confusion. The challenge in directly responding to your statement is there's not a clear cut-off between "install" and "configure." To install, generally, means something like "situate artifacts so the user can make use of them". Often, this is simply adding a directory to PATH. Guix isn't that simple. It requires setting up the store, var/guix, configuring the demon, setting up profiles, and other things. That's all part of "so the user can make use of them" which is more "configuration" than "installation". Which specific configuration is necessary, however, depends on the system and the user. Detailing that at the level of "type this, type that" requires many caveats, explanations, and updates that don't really address the core topic: get Guix on a reader's system so that they can use it. That, as far as I can tell, is the fundamental reason why 'guix-install.sh' exists. What do you think is lost that isn't captured by the following bulleted list? +The script guides you through the following: +@itemize +@item Download and extract the binary tarball +@item Set up the build daemon +@item Make the ‘guix’ command available to non-root users +@item Configure substitute servers +@end itemize > Therefore, the sentence would have to be removed: “The following sections describe two methods of installation, binary installation and building from source.” I've removed that sentence for a different reason. I also revised the sentence, "This is often quicker than installing from source, which is described in the next sections", to simply, "described later". The reason is that Chapter 2 doesn't currently explain building or installing from source. Building and installing from source is currently covered much later in Section 22.1. Whether or not the Installation section should cover building from source is a separate issue and shouldn't be part of this discussion. > Also, > > Matt matt@excalamus.com> writes: > > - Add commas in appropriate places; after "For...Ubuntu-based systems", "Likewise", and the 'or' within the list of substitutes > > I’m not a native speaker, but I believe the commas are not necessary. There particularly does not need to be an Oxford comma before ‘or’. There could be, but there is no reason to change it. Ah, the One True Brace Style of natural language :) I think there's already enough controversy in this thread. I've changed it back :) > Similarly, IMO the nuances are more appropriate in the old wording “For Debian or a derivative such as Ubuntu,” rather than your change “For Debian and Ubuntu-based systems”. 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 explicit. > At the beginning, “You can install the Guix package management tool on top of an existing” makes it appear as if Guix were not a distribution. It is both a tool and a distro. A distro does not need to be an OS. For example, MSYS2 is a distribution. I therefore nitpickingly prefer “You can install Guix”. Admittedly, the wording was vague before, perhaps deliberately. I don't follow you. The complete sentence is: "You can install the Guix package management tool on top of an existing GNU/Linux or GNU/Hurd system, referred to as a foreign distro, or as a standalone operating system distribution, the Guix System." What about that is unclear? > “Use of @file{guix-install.sh} requires Bash, GNU@tie{}tar, wget, and Xz.” is incomplete when applied to guix-install.sh, which also requires GnuPG. Added! Thank you. An updated diff is included. I tried to split it into separate commits but couldn't. That's very, very hard and probably impossible to do in an independent way. My hope is that we can settle on language for this topic and try for a more step-wise approach on the next feedback item.