advanced help
per page, with , order by , clip by
Results of 0 - 1 of about 0 (0.002 sec.)
GNU Guix参考手册
@digest: 1258a5696a435971be89d6639234c23f
@id: 74574
@mdate: 2019-05-19T21:18:27Z
@size: 1805994
@type: text/html
content-type: text/html; charset=utf-8
description: GNU Guix参考手册
distribution: global
generator: makeinfo
keywords: GNU Guix参考手册
resource-type: document
#keywords: 后台 (293965), 构建 (220271), 进程 (200823), 台进 (200360), 调用 (192292), 安装 (173095), 用gu (162621), 务: (137455), 设置 (126655), 件包 (106463), 统安 (106072), 仓库 (102360), 默认 (90120), 服务 (88021), 机器 (86001), 的构 (80686), 文件 (71837), 运行 (61627), 系统 (60545), （se (57653), guix (55031), 环境 (54647), 测试 (53520), 命令 (48872), 输出 (47856), generations (42937), inferior (37891), 执行 (37147), 这个 (36921), 用户 (36348), 软件 (32515), 定义 (32179)
GNU Guix参考手册 Table of Contents 1 介绍 1.1 以Guix的方式管理软件 1.2 GNU发行版 2 安装 2.1 二进制文件安装 2.2 需求 2.3 运行测试套件 2.4 设置后台进程 2.4.1 设置构建环境 2.4.2 使用任务下发设施 2.4.3 SELinux的支持 2.4.3.1 安装SELinux策略 2.4.3.2 限制 2.5 调用 guix-daemon 2.6 设置应用程序 2.6.1 区域 2.6.2 Name Service Switch 2.6.3 X11 Fonts 2.6.4 X.509证书 2.6.5 Emacs Packages 2.6.6 The GCC toolchain 3 系统安装 3.1 限制 3.2 硬件的考虑 3.3 U盘和DVD安装 Copying to a USB Stick Burning on a DVD Booting 3.4 准备安装 3.5 指导的图形安装 3.6 手动安装 3.6.1 Keyboard Layout, Networking, and Partitioning 3.6.1.1 键盘布局 3.6.1.2 Networking 3.6.1.3 Disk Partitioning 3.6.2 继续安装步骤。 3.7 系统安装之后 3.8 Installing Guix in a Virtual Machine 3.9 构建安装镜像 3.10 Building the Installation Image for ARM Boards 4 软件包管理 4.1 功能 4.2 Invoking guix package 4.3 Substitutes 4.3.1 官方的substitute服务器 4.3.2 授权substitute服务器。 4.3.3 验证substitute 4.3.4 代理设置 4.3.5 substitute失败 4.3.6 关于信任二进制文件 4.4 有多个输出的软件包 4.5 Invoking guix gc 4.6 Invoking guix pull 4.7 通道 4.7.1 Using a Custom Guix Channel 4.7.2 Specifying Additional Channels 4.7.3 Declaring Channel Dependencies 4.7.4 Replicating Guix 4.8 Inferiors 4.9 Invoking guix describe 4.10 Invoking guix archive 5 开发 5.1 Invoking guix environment 5.2 Invoking guix pack 6 编程接口 6.1 软件包模块 6.2 定义软件包 6.2.1 package Reference 6.2.2 origin Reference 6.3 构建系统 6.4 仓库 6.5 Derivations 6.6 仓库monad 6.7 G-表达式 6.8 Invoking guix repl 7 工具 7.1 调用 guix build 7.1.1 普通的构建选项 7.1.2 软件包变换选项。 7.1.3 额外的构建选项 7.1.4 调试构建错误 7.2 Invoking guix edit 7.3 Invoking guix download 7.4 Invoking guix hash 7.5 Invoking guix import 7.6 Invoking guix refresh 7.7 Invoking guix lint 7.8 Invoking guix size 7.9 Invoking guix graph 7.10 Invoking guix publish 7.11 Invoking guix challenge 7.12 Invoking guix copy 7.13 Invoking guix container 7.14 Invoking guix weather 7.15 Invoking guix processes 8 系统配置 8.1 使用配置系统 Bootloader Globally-Visible Packages System Services Instantiating the System The Programming Interface 8.2 operating-system Reference 8.3 文件系统 8.4 映射的设备 8.5 用户帐号 8.6 键盘布局 8.7 区域 8.7.1 Locale Data Compatibility Considerations 8.8 服务 8.8.1 基础服务 8.8.2 执行计划任务 8.8.3 日志轮替 8.8.4 网络服务 8.8.5 X窗口 8.8.6 打印服务 8.8.7 桌面服务 8.8.8 声音服务 8.8.9 数据库服务 8.8.10 邮件服务 8.8.11 消息服务 8.8.12 电话服务 8.8.13 监控服务 8.8.14 Kerberos服务 8.8.15 LDAP Services 8.8.16 Web服务 8.8.17 证书服务 8.8.18 DNS服务 8.8.19 VPN服务 8.8.20 网络文件系统 8.8.21 持续集成 8.8.22 电源管理服务 8.8.23 音频服务 8.8.24 Virtualization services 8.8.25 版本控制服务 8.8.26 游戏服务 8.8.27 其它各种服务 8.8.28 Dictionary Services 8.9 setuid程序 8.10 X.509证书 8.11 Name Service Switch 8.12 初始的内存虚拟硬盘 8.13 引导设置 8.14 Invoking guix system 8.15 Running Guix in a Virtual Machine 8.15.1 Connecting Through SSH 8.15.2 Using virt-viewer with Spice 8.16 定义服务 8.16.1 合成服务 8.16.2 服务类型和服务 8.16.3 服务参考 8.16.4 Shepherd服务 9 文档 10 安装调试文件 11 安全更新 12 引导 Preparing to Use the Bootstrap Binaries Building the Build Tools Building the Bootstrap Binaries Reducing the Set of Bootstrap Binaries 13 Porting to a New Platform 14 贡献 14.1 从Git构建 14.2 在安装之前运行Guix 14.3 完美的配置 14.4 打包指导 14.4.1 软件自由 14.4.2 软件包命名 14.4.3 版本号 14.4.4 简介和描述 14.4.5 Python模块 14.4.5.1 指定依赖 14.4.6 Perl模块 14.4.7 Java包 14.4.8 字体 14.5 代码风格 14.5.1 编程范例 14.5.2 模块 14.5.3 数据类型和模式匹配 14.5.4 格式化代码 14.6 提交补丁 发送补丁系列 15 致谢 Appendix A GNU自由文档许可证 概念索引 编程索引 Next: 介绍 , Up: (dir) [ Contents ][ Index ] GNU Guix 这份文档介绍GNU Guix版本1.0.1,一个为GNU系统编写的函数式包管理器。 This manual is also available in Simplified Chinese (see GNU Guix参考手册 ), French (see Manuel de référence de GNU Guix ), German (see Referenzhandbuch zu GNU Guix ), Spanish (see Manual de referencia de GNU Guix ), and Russian (see Руководство GNU Guix ). If you would like to translate it in your native language, consider joining the Translation Project . • 介绍 : Guix是关于什么的? • 安装 : 安装Guix。 • 系统安装 : 安装整个操作系统。 • 软件包管理 : 软件包安装,升级,等 • 开发 : Guix辅助的软件开发。 • 编程接口 : 在Scheme里使用Guix。 • 工具 : 软件包管理命令。 • 系统配置 : 配置操作系统。 • 文档 : 浏览软件用户手册。 • 安装调试文件 : 为调试工具提供输入。 • 安全更新 : 快速部署安全补丁。 • 引导 : 从头开始构建GNU/Linux。 • 移植 : 以别的平台或内核为目标。 • 贡献 : 你需要帮助! • 致谢 : 感谢! • GNU自由文档许可证 : 这个用户手册的许可证。 • 概念索引 : 概念。 • 编程索引 : 数据类型、函数和变量。 －－－详细的章节列表－－－ 介绍 • 以Guix的方式管理软件 : 特殊的地方。 • GNU发行版 : 软件包和工具。 安装 • 二进制文件安装 : 立刻运行Guix! • 需求 : 构建和运行Guix需要的软件。 • 运行测试套件 : 测试Guix。 • 设置后台进程 : 准备“构建后台进程”的环境。 • 调用guix-daemon : 运行“构建后台进程” • 设置应用程序 : 应用程序相关的设置。 设置后台进程 • 设置构建环境 : 准备隔离的构建环境。 • 下发工作给后台进程的设置 : 下发构建工作给远程的机器。 • SELinux的支持 : 为后台进程使用SELinux规则。 系统安装 • 限制 : 你可以期待什么。 • 硬件的考虑 : 支持的硬件。 • U盘和DVD安装 : 准备安装介质。 • 准备安装 : 网络、分区、等 • 指导的图形安装 : 简单的图形安装 • 手动安装 : 适合巫师的手动安装。 • 系统安装之后 : 当安装成功后。 • 在虚拟机里安装Guix。 : Guix系统游乐场。 • 构建安装镜像 : 这是怎样实现的。 手动安装 • 键盘布局、网络和分区 : 初始设置。 • 继续安装步骤。 : 安装。 软件包管理 • 功能 : Guix怎样让你的生活更美好。 • 调用guix package : 软件包安装,删除,等 • Substitutes : 下载构建好的二进制文件。 • 有多个输出的软件包 : 单个输入多个输出的软件包。 • 调用guix gc : 运行垃圾回收器。 • 调用guix pull : 获取最新的Guix和发行版。 • 通道 : 定制软件包集合。 • Inferiors : 和其它版本的Guix交互。 • 调用guix describe : 显示你的Guix版本信息。 • 调用guix archive : 导出和导入仓库文件。 Substitutes • 官方的substitute服务器 : substitute的一个特殊来源。 • 授权substitute服务器。 : 怎么开启或关闭substitute。 • 验证substitute : Guix怎样验证substitute。 • 代理设置 : 怎样通过代理获取substitute。 • substitute失败 : 当substitute失败时会发生什么。 • 关于信任二进制文件 : 你怎么信任二进制块。 开发 • 调用guix environment : 设置开发环境。 • 调用guix pack : 创建软件bundle。 编程接口 • 软件包模块 : 从程序员的角度看软件包。 • 定义软件包 : 定义新软件包。 • 构建系统 : 指定如何构建软件包。 • 仓库 : 操纵软件包仓库。 • Derivations : 软件包derivation的底层接口。 • 仓库monad : 仓库的纯函数式接口。 • G-表达式 : 操纵构建表达式。 • 调用guix repl : 交互式地操作Guix。 定义软件包 • 软件包引用 : 软件包数据类型。 • origin参考手册 : origin数据类型。 工具 • 调用guix build : 用命令行构建软件包。 • 调用guix edit。 : 编辑软件包定义。 • 调用guix download : 下载一个文件并打印它的hash。 • 调用guix hash : 计算一个文件的密码学hash。 • 调用guix import : 导入软件包定义。 • 调用guix refresh : 更新软件包定义。 • 调用guix lint : 从软件包定义里寻找错误。 • 调用guix size : 分析硬盘使用情况。 • 调用guix graph : 展示软件包的关系图。 • 调用guix publish : 分享substitute。 • 调用guix challenge : 挑战subtitute服务器。 • 调用guix copy : 复制到远程的仓库,或从远程的仓库复制。 • 调用guix container : 进程隔离。 • 调用guix weather : 评估substitute的可用性。 • 调用guix processes : 列出客户端进程。 调用 guix build • 普通的构建选项 : 大部分命令的构建选项。 • 软件包变换选项。 : 创建软件包的变体。 • 额外的构建选项 : 只属于'guix build'的选项。 • 调试构建错误 : 真实的打包经验。 系统配置 • 使用配置系统 : 定制你的GNU系统。 • 操作系统参考 : 操作系统声明详情。 • 文件系统 : 设置文件系统挂载。 • 映射的设备 : 块设备额外的处理。 • 用户帐号 : 指定用户帐号。 • 键盘布局 : 系统怎样理解按键。 • 区域 : 语言和文化惯例设置。 • 服务 : 指定系统服务。 • setuid程序 : 以root权限运行的程序。 • X.509证书 : 认证HTTPS服务器。 • Name Service Switch : 设置libc的name service switch。 • 初始的内存虚拟硬盘 : Linux-Libre引导。 • 引导设置 : 设置引导程序。 • 调用guix system : 实例化一个系统配置。 • 在虚拟机里运行Guix : 怎样在虚拟机里运行Guix。 • 定义服务 : 添加新的服务定义。 服务 • 基础服务 : 必要的系统服务。 • 执行计划任务 : mcron服务。 • 日志轮替 : rottlog服务。 • 网络服务 : 网络设置,SSH后台进程,等 • X窗口 : 图形显示器。 • 打印服务 : 本地和远程打印机的支持。 • 桌面服务 : D-Bus和桌面服务。 • 声音服务 : ALSA和Pulseaudio服务。 • 数据库服务 : SQL数据库,键值仓库,等 • 邮件服务 : IMAP,POP3,SMTP,等 • 消息服务 : 消息服务。 • 电话服务 : 电话服务。 • 监控服务 : 监控服务。 • Kerberos服务 : Kerberos服务。 • Web服务 : Web服务。 • 证书服务 : Let's Encrypt TLS证书。 • DNS服务 : DNS后台进程。 • VPN服务 : VPN后台进程。 • 网络文件系统 : 网络文件系统相关的服务。 • 持续集成 : Cuirass服务。 • 电源管理服务 : 延长电池寿命。 • 音频服务 : MPD。 • 虚拟化服务 : 虚拟化服务。 • 版本控制服务 : 远程访问Git仓库。 • 游戏服务 : 游戏服务器。 • 其它各种服务 : 其它服务。 定义服务 • 合成服务 : 服务合成的模型。 • 服务类型和服务 : 类型和服务。 • 服务参考 : API参考。 • Shepherd服务 : 一种特别的服务。 Next: 安装 , Previous: Top , Up: Top [ Contents ][ Index ] 1 介绍 GNU Guix 1 是GNU系统的包管理器和发行版。Guix让无特权的用户可以轻松地安装,升级,或删除软件包,回滚到前一个软件包集合,从源代码构建软件包,及辅助软件环境的创建和维护。 你可以在现有的GNU/Linux发行版上安装GNU Guix（see 安装 ）,Guix可以补充已有的工具,并且不会和它们产生冲突。或者你可以把它当作独立的操作系统发行版（ Guix 系统 2 ）。See GNU发行版 . • 以Guix的方式管理软件 : 特殊的地方。 • GNU发行版 : 软件包和工具。 Next: GNU发行版 , Up: 介绍 [ Contents ][ Index ] 1.1 以Guix的方式管理软件 Guix提供了命令行软件包管理接口（see 软件包管理 ）,辅助软件开发的工具（see 开发 ）,高级用法的命令行接口（see 工具 ）,以及Scheme编程语言接口（see 编程接口 ）。 构建后台进程 为用户构建软件包（see 设置后台进程 ）,及从授权的源（see Substitutes ）下载预构建的二进制文件。 Guix包含很多GNU和非GNU的软件包定义,所有的这些软件包都 尊重用户的自由 。它是 可扩展的 :用户可以编写自己的软件包定义（see 定义软件包 ）,并且把它们作为独立的软件包模块see 软件包模块 。它也是 可定制的 :用户可以从现有的软件包定义衍生出特殊的软件包,包括从命令行（see 软件包变换选项。 ）。 在底层,Guix实现了由Nix（see 致谢 ）开创的 函数式包管理器 。在Guix里,软件包构建和安装过程被视为数学意义上的 函数 。函数获取输入,如构建脚本、编译器和库,并且返回一个安装好的软件包。作为一个纯函数,它的结果只取决于它的输入－－例如,它不能引用没有作为显式输入传入的软件和脚本。当传入特定的输入时,一个构建函数总是得到相同的结果。它不能以任何方式修改运行系统的环境,例如,它不能创建,修改,或删除构建和安装环境之外的文件夹。这是通过在隔离的环境（ 容器 ）里运行构建进程实现的,在这个环境里只能访问到显式的输入。 软件包构建函数的结果被 缓存 在文件系统里的一个叫做 仓库 （see 仓库 ）的特殊文件夹内。每个软件包都被安装在仓库（默认在 /gnu/store ）里的一个独立的文件夹内。这个文件夹的名字含有用于构建这个软件包的所有输入的hash,所以,修改输入会得到一个不同的文件夹名。 这种手段是实现Guix的突出功能的基础:对事务型软件包升级和回滚的支持,每个用户独立的安装,软件包垃圾回收see 功能 。 Previous: 以Guix的方式管理软件 , Up: 介绍 [ Contents ][ Index ] 1.2 GNU发行版 Guix提供了一个GNU系统发行版,这个发新版只包含自由软件 3 。这个发行版可以独立安装（see 系统安装 ）,但是把Guix安装为一个已经安装好的GNU/Linux系统的包管理器也是可行的（see 安装 ）。当我们需要区分这两者时,我们把独立的发行版称为“Guix系统”。 这个发行版提供了GNU核心软件包,如libc、gcc和Binutils,以及很多GNU和非GNU应用程序。可用的软件包的完整列表可以在 on-line 浏览,或者通过运行 guix package （see 调用guix package ）获得: guix package --list-available 我们的目标是提供一个基于Linux和其它GNU变体的可用的100%自由的软件发行版,我们的重点是推广和紧密集成GNU组件,以及强调帮助用户行使那些自由的程序和工具。 目前这些平台提供软件包: x86_64-linux Intel/AMD x86_64 架构,Linux-Libre内核; i686-linux Intel 32位架构（IA32),Linux-Libre内核; armhf-linux ARMv7-A架构,带硬件浮点数、Thumb-2和NEON扩展,EABI硬件浮点数应用二进制接口（ABI）,和Linux-Libre内核。 aarch64-linux little-endian 64-bit ARMv8-A processors, Linux-Libre kernel. mips64el-linux little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, the project's build farms no longer provide substitutes for this architecture. 在Guix系统里,你 声明 操作系统所有方面的配置,然后Guix以事务型的,可重复的,和无状态的方式解决实例化配置的问题（see 系统配置 ）。Guix系统使用Linux-Libre内核,Shepherd初始化系统see 介绍 in GNU Shepherd用户手册 ,知名的GNU工具和工具链,以及你可选的图形界面环境和系统服务。 Guix系统在上面所有的平台上都可用,除了 mips64el-linux 。 关于移植到其它架构或内核的信息,see 移植 。 构建这个发行版需要努力合作,欢迎你加入!关于你可以怎样提供帮助的信息,See 贡献 。 Next: 系统安装 , Previous: 介绍 , Up: Top [ Contents ][ Index ] 2 安装 注: 我们推荐使用 shell安装脚本 在已有的GNU/Linux系统（即 foreign distro ）上安装Guix。 4 这个脚本自动下载、安装并且初始化Guix,它需要以root用户身份运行。 在foreign distro上安装时,GNU Guix可以在不引起冲突的前提下补充现有的工具。它的数据只存放在两个文件夹里,通常是 /gnu/store 和 /var/guix ;系统上的其它文件,如 /etc ,不会被修改。 一旦安装好了,可以通过运行 guix pull 升级Guix（see 调用guix pull ）。 如果你希望手动执行安装步骤,或者想改变安装步骤,接下来这些小节会很有用。它们介绍Guix的软件依赖,以及如何手动安装和使用Guix。 • 二进制文件安装 : 立刻运行Guix! • 需求 : 构建和运行Guix需要的软件。 • 运行测试套件 : 测试Guix。 • 设置后台进程 : 准备“构建后台进程”的环境。 • 调用guix-daemon : 运行“构建后台进程” • 设置应用程序 : 应用程序相关的设置。 Next: 需求 , Up: 安装 [ Contents ][ Index ] 2.1 二进制文件安装 这个小节介绍如何在任意的系统上用独立的Guix二进制文件包安装Guix和它的依赖。这通常比从源代码安装更快,下一小节会介绍如何从源代码安装。唯一的需求是有GNU tar和Xz。 注: 我们推荐使用这个 shell安装脚本 。这个脚本自动执行下述的下载、安装并且初始化Guix的过程。它需要以root用户身份运行。 安装步骤如下: 从‘ https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1. 系统 .tar.xz '下载二进制安装包,对于运行Linux内核的 x86_64 机器来说 系统 是 x86_64-linux ,以此类推。 请确保下载相关的 .sig 文件,并且用它验证文件包的可靠性,方法如下: $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1. 系统 .tar.xz.sig $ gpg --verify guix-binary-1.0.1. 系统 .tar.xz.sig 如果那个命令因为缺少所需的公钥而失败了,那么用这个命令导入它: $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 再次运行 gpg --verify 命令。 现在你需要成为 root 用户。基于你的发行版,你可能需要执行 su - 或 sudo -i 。以 root 用户身份,执行: # cd /tmp # tar --warning=no-timestamp -xf \ guix-binary-1.0.1. 系统 .tar.xz # mv var/guix /var/ && mv gnu / 这会创建 /gnu/store （see 仓库 ）和 /var/guix 。后一个文件夹为 root 用户提供了一个立即可用的profile（见下一步）。 不要 在一个正常的Guix系统上解压这个文件包,因为那会把现有的重要的文件覆盖。 --warning=no-timestamp 选项使GNU tar不输出有关“implausibly old time stamps”的警告（这类警告会被GNU tar 1.26或更老的版本触发;新的版本没事）。这类警告是因为文件包里的所有文件的修改时间戳都被设置为0(即1970年1月1日）。这是故意的,为了确保文件包的内容独立于创建的时间,从而使它可再现。 使profile出现在 ~root/.config/guix/current ,这是 guix pull 安装更新的位置（see 调用guix pull ）: # mkdir -p ~root/.config/guix # ln -sf /var/guix/profiles/per-user/root/current-guix \ ~root/.config/guix/current 执行 etc/profile 以更新 PATH 和其它相关的环境变量: # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \ source $GUIX_PROFILE/etc/profile 像下面解释的那样为“构建用户”创建用户组和用户（see 设置构建环境 ）。 运行后台进程,并设置为开机自启动。 如果你的主机的发行版使用systemd init系统,可以用这些命令: # cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon 如果你的主机的发行版使用Upstart init系统: # initctl reload-configuration # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \ /etc/init/ # start guix-daemon 此外,你可以手动启动后台进程: # ~root/.config/guix/current/bin/guix-daemon \ --build-users-group=guixbuild 使机器上的其他用户也可以使用 guix 命令: # mkdir -p /usr/local/bin # cd /usr/local/bin # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix 最好让这个用户手册的Info版也可以被访问: # mkdir -p /usr/local/share/info # cd /usr/local/share/info # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ; do ln -s $i ; done 那样,假设 /usr/local/share/info 在搜索路径里,运行 info guix 命令就会打开这个用户手册（see Other Info Directories in GNU Texinfo ,更多关于Info搜索路径的信息）。 为了使用 ci.guix.gnu.org 或其镜像的substitute（see Substitutes ）,对其授权: # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub 每个用户可能需要执行一些额外的步骤以使各自的Guix环境可用,see 设置应用程序 。 瞧,安装完成了! 你可以通过给root profile安装一个软件包来确认Guix可以正常工作。 # guix install hello 二进制安装包可以通过在Guix源代码树里运行下面这些命令来重现和验证: make guix-binary. 系统 .tar.xz ... 这个命令会执行: guix pack -s 系统 --localstatedir \ --profile-name=current-guix guix See 调用guix pack ,了解这个方便的工具。 Next: 运行测试套件 , Previous: 二进制文件安装 , Up: 安装 [ Contents ][ Index ] 2.2 需求 这个小节列举了从源代码构建Guix的需求。构建Guix的步骤和其它GNU软件相同,这里不介绍。请阅读Guix源代码树里的 README 和 INSTALL 文件以了解更多的信息。 GNU Guix可以从它的网站下载 https://www.gnu.org/software/guix/ 。 GNU Guix依赖这些软件包: GNU Guile ,版本2.2.x; Guile-Gcrypt ,版本 0.1.0或更新; GnuTLS ,特别是它的Guile接口（see 怎样为Guile安装GnuTLS接口 in GnuTLS-Guile ）; Guile-SQLite3 ,版本0.1.0或更新; Guile-Git ,2017年8月及之后的版本; Guile-JSON ; zlib ; GNU Make 。 这些依赖是可选的: 对下发构建任务（see 下发工作给后台进程的设置 ）和 guix copy （see 调用guix copy ）的支持依赖于 Guile-SSH ,版本0.10.2或更新。 当 libbz2 存在时, guix-daemon 可以用它压缩构建日志。 除非 --disable-daemon 参数被传给 configure ,这些软件包也是需要的依赖: GNU libgcrypt ; SQLite 3 ; GCC's g++ ,支持 C++11标准。 当在一个已经安装Guix的系统上配置Guix时,请确保用 configure 的 --localstatedir 参数指定和现有的安装相同的状态文件夹（see localstatedir in GNU Coding Standards ）。 configure 保护你免于误设置 localstatedir ,从而不会无意中损坏仓库（see 仓库 ）。 当一个已经安装的且可用的 Nix包管理器 存在时,你可以为Guix配置 --disable-daemon 参数。那样Nix可以替换上面的三个依赖。 Guix和Nix兼容,所以两者共享相同的仓库是可行的。如果这样做,你必须传给 configure 相同的 --with-store-dir ,以及相同的 --localstatedir 。后者很重要,因为它指定了储存仓库元数据以及其它信息的数据库的位置,。Nix的默认值是 --with-store-dir=/nix/store 和 --localstatedir=/nix/var 。注意,如果你的目的是和Nix共享仓库,那么 --disable-daemon 参数不是必须的。 Next: 设置后台进程 , Previous: 需求 , Up: 安装 [ Contents ][ Index ] 2.3 运行测试套件 成功执行 configure 和 make 之后,最好运行测试套件。它可以帮助查找设置和环境的错误,或者是Guix自身的bug－－并且,报告测试错误是帮助改进软件的好方法。输入下面的命令以执行测试套件。 make check 测试用例可以并行运行:你可以用GNU make的 -j 参数来加速运行。才一台较新的机器上第一次运行可能会花几分钟,后续的运行会更快,因为为测试创建的仓库已经包含了各种缓存。 你还可以通过定义makefile的 TESTS 变量只运行测试的一个子集: make check TESTS="tests/store.scm tests/cpio.scm" 默认情况下,测试结果只展示到文件层级。为了看每个独立的测试用例的详情,可以像这样定义 SCM_LOG_DRIVER_FLAGS makefile变量: make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no" 遇到错误时,请给 bug-guix@gnu.org 发邮件,并附带 test-suite.log 文件。请在消息里说明使用的Guix的版本信息和依赖（see 需求 ）的版本信息。 Guix还附带了一个可以测试整个Guix系统实例的全系统测试套件。它只能在已经安装Guix的系统上运行: make check-system 或者,同样的,通过定义 TESTS 只运行测试的一个子集: make check-system TESTS="basic mcron" 这些系统测试是在 (gnu tests …) 模块里定义的。它们在虚拟机（VM）里运行轻量的指令。它们的计算量可能很多也可能很少,这取决于它们依赖的substitute（see Substitutes ）是否已经存在。它们之中有些需要很多存储空间以保存虚拟机硬盘。 再重复一遍,如果遇到测试错误,请给 bug-guix@gnu.org 发邮件,并附带详细的说明。 Next: 调用guix-daemon , Previous: 运行测试套件 , Up: 安装 [ Contents ][ Index ] 2.4 设置后台进程 构建软件包或运行垃圾回收器之类的操作都是由一个特殊的进程代替客户执行的,即 构建后台进程 。只有这个进程可以访问仓库和相关的数据库。因此,所有修改仓库的操作都通过这个后台进程执行。例如, guix package 和 guix build 之类的命令行工具通过和这个后台进程通信（ 通过 远程过程调用）来指示它该做什么。 接下来的几个小节介绍如何准备“构建后台进程”的环境。参考 Substitutes ,了解怎样允许这个后台进程下载预构建好的二进制文件。 • 设置构建环境 : 准备隔离的构建环境。 • 下发工作给后台进程的设置 : 下发构建工作给远程的机器。 • SELinux的支持 : 为后台进程使用SELinux规则。 Next: 下发工作给后台进程的设置 , Up: 设置后台进程 [ Contents ][ Index ] 2.4.1 设置构建环境 在一个标准的多用户设置里,Guix和它的后台进程– guix-daemon 程序–是由 root 用户安装的,并且 guix-daemon 以 root 用户身份运行。无特权的用户可以用Guix的工具构建软件包或访问仓库,这个后台进程会代替用户进行这些操作,以确保仓库保持一致的状态,并且允许构建好的软件包可以在不同用户间共享。 当 guix-daemon 以 root 用户身份运行时,由于安全方面的考虑,你可能不希望软件包构建进程也以 root 用户身份运行。为了避免那样,我们需要创建一个 构建用户 池,以供后台进程启动的构建进程使用。这些构建用户不需要拥有shell和家目录:他们只会在后台进程为构建进程剥夺 root 特权时使用。拥有多个这类用户使后台进程可以以不同的UID启动不同的构建进程,这保证它们不会互相干扰–这是一个重要的功能,因为构建被视为纯函数（see 介绍 ）。 在一个GNU/Linux系统上,可以这样创建一个构建用户池（用bash语法和 shadow 命令）: # groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \ -d /var/empty -s `which nologin` \ -c "Guix build user $i" --system \ guixbuilder$i; done 构建用户的数量决定了有多少个构建任务可以并行执行,即 --max-jobs 参数(see --max-jobs )。为了使用 guix system vm 和相关的命令,你需要把构建用户添加到 kvm 用户组,以使它们访问 /dev/kvm 。为此,把 -G guixbuild 替换成 -G guixbuild,kvm （see 调用guix system ）。 之后以 root 身份用下面的命令运行 guix-daemon 程序command 5 : # guix-daemon --build-users-group=guixbuild 这样,后台进程在一个chroot环境里,以一个 guixbuilder 用户组成员的身份启动构建进程。在GNU/Linux上,默认的,这个chroot环境仅包含这些东西: 一个和主机 /dev 独立的 6 ,最小的 /dev 文件夹; /proc 文件夹;它只含有当前容器的进程,因为用了一个独立的进程PID命名空间; /etc/passwd ,仅包含当前用户和 nobody ; /etc/group ,包含用户的组; /etc/hosts ,包含 localhost 映射到 127.0.0.1 的条目; 一个可写的 /tmp 文件夹。 你可以 通过 TMPDIR 环境变量修改后台进程保存构建树的位置。但是,chroot里的构建树总是在 /tmp/guix-build- 名字 .drv-0 , 名字 是derivation的名字–如 coreutils-8.24 。这样, TMPDIR 的值就不会泄漏到构建环境里,这可以避免由构建进程读取构建树名字引起的问题。 后台进程通过HTTP下载时还遵守 http_proxy 环境变量,无论是下载derivation（see Derivations ）,还是下载substitute（see Substitutes ）。 如果你是以无特权的用户的身份安装Guix,你仍可以运行 guix-daemon ,只要添加 --disable-chroot 参数就行了。但是,构建进程不会互相隔离,也不会和系统的其它部分隔离。因此,构建进程有可能互相干扰,可以访问程序、库和系统上的其它文件–这样就很难把它看作 纯 函数。 Next: SELinux的支持 , Previous: 设置构建环境 , Up: 设置后台进程 [ Contents ][ Index ] 2.4.2 使用任务下发设施 当需要时,构建后台进程可以把构建derivation的任务 下发 给其它运行Guix的机器,这通过 下发 构建钩子 实现 7 。当那个功能被启用时,会从 /etc/guix/machines.scm 读取一列用户指定的机器;每次发送构建请求时,如执行 guix build ,后台进程尝试把它下发到某一台满足derivation的约束（特别是系统类型–如 x86_64-linux ）的机器上。缺少的必备构建依赖通过SSH复制到目标机器,然后继续构建;成功后,构建输出的结果被复制回初始的机器上。 /etc/guix/machines.scm 文件通常是这样的: (list (build-machine (name "eightysix.example.org") (system "x86_64-linux") (host-key "ssh-ed25519 AAAAC3Nza…") (user "bob") (speed 2.)) ;非常快! (build-machine (name "meeps.example.org") (system "mips64el-linux") (host-key "ssh-rsa AAAAB3Nza…") (user "alice") (private-key (string-append (getenv "HOME") "/.ssh/identity-for-guix")))) 在上面的例子里,我们指定了一个包含两个构建机器的列表,一个是 x86_64 架构,一个是 mips64el 架构。 事实上,这个文件–并不意外地–是一个Scheme文件,当 下发 钩子被启动时执行。它的返回值必须是一个包含 build-machine 对象的列表。虽然这个例子展示的是一个固定的列表,你可以想象,使用DNS-SD来返回一个包含从局域网内发现的构建机器的列表,see Guile-Avahi in 在Guile Scheme程序里使用Avahi 。 build-machine 数据类型的详细信息如下。 数据类型: build-machine 这个数据类型表示后台进程可以下发构建任务的构建机器。重要的项有: 名字 远程机器的主机名。 系统 远程机器的系统类型–如, "x86_64-linux" 。 用户 通过SSH连接远程机器时使用的用户帐号。注意,SSH密钥 不 能被密码保护,以支持无交互的登录。 主机公钥 这必须是机器的OpenSSH格式的SSH 公钥 。这是用来在连接机器时认证身份的。它是一个像这样的长字符串: ssh-ed25519 AAAAC3NzaC…mde+UhL hint@example.org 如果这个机器正在运行OpenSSH后台进程, sshd ,那么主机公钥可以在 /etc/ssh/ssh_host_ed25519_key.pub 找到。 如果这个机器正在运行GNU lsh, lshd ,那么主机公钥可以在 /etc/lsh/host-key.pub 或类似的位置找到。它可以通过 lsh-export-key 命令转换成OpenSSH格式（see Converting keys in LSH用户手册 ）: $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV… 一些可选的项: port （默认值: 22 ） 机器上的SSH服务器的端口号。 private-key （默认值: ~root/.ssh/id_rsa ） 连接机器时使用的SSH私钥,OpenSSH格式。这个私钥不能被密码保护。 注意,默认值是 root帐号 的私钥。使用默认值时请确保它存在。 compression （默认值: "zlib@openssh.com,zlib" ） compression-level （默认值: 3 ） SSH压缩算法和压缩级别。 下发任务依赖SSH压缩来减少传输文件到构建机器时使用的带宽。 daemon-socket （默认值: "/var/guix/daemon-socket/socket" ） 那台机器上的 guix-daemon 监听的Unix套接字文件名。 parallel-builds （默认值: 1 ） 那台机器上可以并行运行的构建任务数量。 speed （默认值: 1.0 ） 一个相对的速度值。下发调度器会偏好速度更快的机器。 features （ '() ） 一个表示机器支持的功能的字符串列表。例如, "kvm" 表示机器有KVM Linux模块和相关的硬件支持。Derivation可以通过名字请求需要的功能,然后被分发到匹配的机器的任务队列里。 guix 命令必须在构建机器的搜素路径里。你可以通过这个命令检查: ssh build-machine guix repl --version machines.scm 到位后,还有一件要做的事。如上所述,下发任务时会在机器的仓库之间传输文件。为此,你需要在每台机器上生成一个密钥对,以使后台进程可以从仓库导出签名后的文件包（see 调用guix archive ）: # guix archive --generate-key 每台构建机器都必须认证主机器的公钥,从而接收从主机器接收的仓库文件: # guix archive --authorize < master-public-key.txt 类似的,主机器必须认证每台构建机器的公钥: 所有这些有关公钥的繁琐事宜都是为了表达主服务器和构建服务器之间成对的互相信任关系。具体地,当主机器从构建机器接收文件时（反之亦然）,它的构建后台进程可以确保文件是原样的,没有被篡改,并且被认证的公钥签名过。 为了测试你的设置是否能正常工作,在主节点上运行这个命令: # guix offload test 这会尝试连接每台在 /etc/guix/machines.scm 里指定的构建机器,确保Guile和Guix模块在每台机器上都可用,尝试导出到这些机器和从这些机器导入,并且报告这个过程中遇到的任何错误。 如果你希望用别的文件测试,只需要在命令行指定它: # guix offload test machines-qualif.scm 最后,你可以像这样只测试机器列表里名字匹配某个正则表达式的子集: # guix offload test machines.scm '\.gnu\.org$' 若想展示所有构建主机的当前负载,在主节点上运行这个命令: # guix offload status Previous: 下发工作给后台进程的设置 , Up: 设置后台进程 [ Contents ][ Index ] 2.4.3 SELinux的支持 Guix附带一个SELinux策略文件,位置在 etc/guix-daemon.cil ,它可以在启用SELinux的系统上安装,为Guix的文件添加标签及指定后台进程的期望行为。由于Guix系统不提供SELinux基础策略,这个后台进程策略不能在Guix系统上使用。 2.4.3.1 安装SELinux策略 用root用户执行这个命令以安装策略: semodule -i etc/guix-daemon.cil 用 restorecon 或者你的系统提供的其它机制重新给文件系统打标签。 一旦安装好策略,为文件系统重新打好标签,并且重启了后台进程,它应该在 guix_daemon_t 环境里运行。你可以用下面这个命令确认: ps -Zax | grep guix-daemon 运行 guix build hello 之类的命令并监控SELinux日志以说服你自己SELinux允许所有的操作。 2.4.3.2 限制 这个策略不是完美的。这里有一个关于限制和缺陷的列表,当为Guix后台进程部署提供的SELinux策略时该认真考虑。 guix_daemon_socket_t 没有被实际使用。所有的套接字操作都和 guix_daemon_socket_t 没有任何关系。存在这个没被使用的标签并不碍事,但是为这个标签定义套接字规则是更好的选择。 guix gc 不可以任意访问指向profile的链接。由于设计的原因,符号链接的目标的文件标签和符号链接本身的文件标签是不同的。尽管$localstatedir里的所有profile都被打上了标签,指向这些profile的符号链接继承它们所在的文件夹的标签。对于普通用户的家目录里的链接,标签是 user_home_t 。但是对于root用户的家目录,或 /tmp ,或HTTP服务器的工作目录等文件夹里的链接不是这样。 guix gc 会被阻止读取和跟随这些链接。 后台进程监听TCP连接的功能不再可用。这可能需要额外的规则,因为SELinux区别对待网络套接字和文件。 目前,所有匹配正则表达式 /gnu/store/.+-(guix-.+|profile)/bin/guix-daemon 的文件都被赋予 guix_daemon_exec_t 标签;这意味着 任何 profile里的任何有这样名字的的文件都会被允许在 guix_daemon_t 域里执行。这不够理想。一个攻击者可以构建提供这个可执行程序的软件包,并说服一个用户安装、运行它,以此进入 guix_daemon_t 域。那时,SELinux无法阻止它访问所在域的进程可以访问的文件。 我们可以在安装时生成一个更严格的策略,仅当前安装的 guix-daemon 的 精确的 的文件名会被打上 guix_daemon_exec_t 标签,而不是用一个宽泛的正则表达式。这样的缺点是root必须在每次安装提供 guix-daemon 的Guix软件包时安装或升级策略。 Next: 设置应用程序 , Previous: 设置后台进程 , Up: 安装 [ Contents ][ Index ] 2.5 调用 guix-daemon guix-daemon 程序实现了所有访问仓库的功能。包括启动构建进程,运行垃圾回收器,查询构建结果,等。它通常以 root 身份运行: # guix-daemon --build-users-group=guixbuild 关于如何设置它,see 设置后台进程 。 默认情况下, guix-daemon 用不同的UID启动构建进程,这些用户是从 --build-users-group 参数指定的用户组里获取的。并且,每个构建进程都在一个chroot环境里运行,这个环境只包含构建进程依赖的仓库的子集（由derivation（see derivation ）的内容决定）,以及一些系统文件夹。默认情况下,后者包含 /dev 和 /dev/pts 。并且,在GNU/Linux上,构建环境是一个 容器 :它不仅有自己的文件系统树,还有独立的挂载命名空间,独立的PID命名空间,网络命名空间,等。这帮助实现可复现构建的目的（see 功能 ）。 当后台进程代替用户执行构建时,它在 /tmp 或 TMPDIR 环境变量指定的文件夹里创建一个文件夹。在构建期间,这个文件夹被共享给容器,然而容器内,这个构建树总是叫做 /tmp/guix-build- name .drv-0 。 结束时构建文件夹就被自动删除了,除非构建失败并且客户端指定了 --keep-failed 参数（see --keep-failed ）。 后台进程监听连接并且为每个客户端（ guix 的子命令）启动的会话生成一个子进程。 guix processes 命令允许你获取系统上的活动的概况,浏览每个活动会话和客户端。See 调用guix processes ,以了解更多信息。 下面这些命令行选项受支持: --build-users-group= 用户组 这会从 用户组 里选取用户,以运行构建进程（see 构建用户 ）。 --no-substitutes 不要为构建商品使用substitute。即,总是在本地构建,而不是下载预构建的二进制文件（see Substitutes ）。 当后台进程用 --no-substitutes 参数启动时,客户端仍然可以显式地 通过 set-build-options 远程过程调用来启用substitute（see 仓库 ）。 --substitute-urls= urls urls 是用空格分隔的substitute源URL列表。当这个选项被省略时,默认使用‘ https://ci.guix.gnu.org '。 这意味着可以从 urls 下载substitute,只要它们的签名可信（see Substitutes ）。 --no-build-hook 不要使用 构建钩子 。 构建钩子是一个可以被后台进程启动并且提交构建请求的辅助程序。这个机制被用来向其它机器下发构建。（see 下发工作给后台进程的设置 ）。 --cache-failures 缓存失败的构建。默认地,只缓存成功的构建。 当这个选项被使用时,可以用 guix gc --list-failures 查询被标记为失败的仓库文件; guix gc --clear-failures 从仓库里删除失败的缓存。See 调用guix gc 。 --cores= n -c n 用 n 个CPU核来构建每个derivation; 0 表示有多少就用多少。 默认值是 0 ,但是它的值可以被客户端覆盖,例如 guix build 的 --cores 选项（see 调用guix build ）。 他的作用是在构建进程里设置 NIX_BUILD_CORES 环境变量,从而用它来利用内部的并行机制–例如,通过运行 make -j$NIX_BUILD_CORES 。 --max-jobs= n -M n 最多允许 n 个并行的构建任务。默认值是 1 。设置为 0 表示不在本地执行构建;而是下发构建任务（see 下发工作给后台进程的设置 ）,或者直接失败。 --max-silent-time= seconds 当构建或substitution进程超过 seconds 秒仍然保持静默,就把它结束掉并报告构建失败。 默认值是 0 ,表示关闭超时。 这里指定的值可以被客户端覆盖（see --max-silent-time ）。 --timeout= seconds 类似地,当构建或substitution进程执行超过 seconds 秒,就把它结束掉并报告构建失败。 默认值是 0 ,表示关闭超时。 这里指定的值可以被客户端覆盖（see --timeout ）。 --rounds= N 为每个derivation构建 n 次,如果连续的构建结果不是每个比特都相同就报告错误。这个设置可以被 guix build 之类的客户端覆盖（see 调用guix build ）。 当和 --keep-failed 一起使用时,不同的输出保存在 /gnu/store/…-check 。这让检查两个结果的区别更容易。 --debug 生成调试输出。 这对调试后台进程的启动问题很有用,但是之后它可能会被客户端覆盖,例如 guix build 命令的 --verbosity 选项（see 调用guix build ）。 --chroot-directory= dir 把 dir 添加到构建的chroot。 这么做可能会改变构建进程的结果–例如,如果它们使用了在 dir 里发现的可选依赖。因此,建议不要这么做,而是确保每个derivation声明所需的全部输入。 --disable-chroot 关闭chroot构建。 不建议使用这个选项,因为它会允许构建进程访问到没被声明的依赖。但是,当 guix-daemon 以没有特权的用户身份运行时,这个选项是必须的。 --log-compression= type 以 type 方式压缩构建日志,可选的值: gzip , bzip2 , none 。 除非使用了 --lose-logs ,所有的构建日志都保存在 localstatedir 里。为了节省空间,后台进程默认使用bzip2对它们进行压缩。 --disable-deduplication 关闭自动对仓库文件“去重”。 默认地,添加到仓库的文件会被自动“去重”:如果新添加的文件和仓库里找到的某个文件完全相同,后台进程把这个新文件变成另一个文件的硬链接。这可以明显地减少硬盘使用,代价是构建结束后轻微地增加输入/输出负载。这个选项关闭这个优化。 --gc-keep-outputs[=yes|no] 垃圾收集器（GC）是否必须保留存活的derivation的输出。 当设置为“yes”时,GC会保留仓库里每个存活的derivation（ .drv 文件）的输出。默认是“no”,表示只有当从GC根可以访问时才保留derivation的输出。See 调用guix gc ,了解更多关于GC根的信息。 --gc-keep-derivations[=yes|no] 垃圾收集器（GC）是否必须保留和存活的输出相关的derivation。 当设置为“yes”时（默认）,只要derivation（即 .drv 文件）的输出至少有一个是存活的,GC就将其保留。这让用户可以追踪仓库里物品的源头。设置为“no”可以节省一点硬盘空间。 这样,设置 --gc-keep-derivations 为“yes”使存活性从“输出”传递到“derivation”,设置 --gc-keep-outputs 为“yes”使存活性从“derivation”传递到“输出”。当两者都设置为“yes”时,效果是保留所有在仓库里的存活对象的构建先决条件（源代码,编译器,库,和其它构建时的工具）,不管这些先决条件是否能从某个GC根访问到。这对开发者来说很方便,因为它避免了重复构建和下载。 --impersonate-linux-2.6 在基于Linux的系统上,伪装成Linux 2.6。这意味着内核的 uname 系统调用会把版本号报告为2.6。 这可能会有助于构建那些（通常是错误地）依赖内核版本号的程序。 --lose-logs 不保留构建日志。默认保存在 localstatedir /guix/log 。 --system= system 假设 system 是当前的系统类型。默认值是configure时发现的架构/内核元组,如 x86_64-linux 。 --listen= endpoint Listen for connections on endpoint . endpoint is interpreted as the file name of a Unix-domain socket if it starts with / (slash sign). Otherwise, endpoint is interpreted as a host name or host name and port to listen to. Here are a few examples: --listen=/gnu/var/daemon Listen for connections on the /gnu/var/daemon Unix-domain socket, creating it if needed. --listen=localhost Listen for TCP connections on the network interface corresponding to localhost , on port 44146. --listen=128.0.0.42:1234 Listen for TCP connections on the network interface corresponding to 128.0.0.42 , on port 1234. This option can be repeated multiple times, in which case guix-daemon accepts connections on all the specified endpoints. Users can tell client commands what endpoint to connect to by setting the GUIX_DAEMON_SOCKET environment variable (see GUIX_DAEMON_SOCKET ). 注: The daemon protocol is unauthenticated and unencrypted . Using --listen= host is suitable on local networks, such as clusters, where only trusted nodes may connect to the build daemon. In other cases where remote access to the daemon is needed, we recommend using Unix-domain sockets along with SSH. When --listen is omitted, guix-daemon listens for connections on the Unix-domain socket located at localstatedir /guix/daemon-socket/socket . Previous: 调用guix-daemon , Up: 安装 [ Contents ][ Index ] 2.6 设置应用程序 When using Guix on top of GNU/Linux distribution other than Guix System—a so-called foreign distro —a few additional steps are needed to get everything in place. Here are some of them. 2.6.1 区域 Packages installed via Guix will not use the locale data of the host system. Instead, you must first install one of the locale packages available with Guix and then define the GUIX_LOCPATH environment variable: $ guix install glibc-locales $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale Note that the glibc-locales package contains data for all the locales supported by the GNU libc and weighs in at around 110 MiB. Alternatively, the glibc-utf8-locales is smaller but limited to a few UTF-8 locales. The GUIX_LOCPATH variable plays a role similar to LOCPATH (see LOCPATH in The GNU C Library Reference Manual ). There are two important differences though: GUIX_LOCPATH is honored only by the libc in Guix, and not by the libc provided by foreign distros. Thus, using GUIX_LOCPATH allows you to make sure the programs of the foreign distro will not end up loading incompatible locale data. libc suffixes each entry of GUIX_LOCPATH with /X.Y , where X.Y is the libc version—e.g., 2.22 . This means that, should your Guix profile contain a mixture of programs linked against different libc version, each libc version will only try to load locale data in the right format. This is important because the locale data format used by different libc versions may be incompatible. 2.6.2 Name Service Switch When using Guix on a foreign distro, we strongly recommend that the system run the GNU C library's name service cache daemon , nscd , which should be listening on the /var/run/nscd/socket socket. Failing to do that, applications installed with Guix may fail to look up host names or user accounts, or may even crash. The next paragraphs explain why. The GNU C library implements a name service switch (NSS), which is an extensible mechanism for “name lookups” in general: host name resolution, user accounts, and more (see Name Service Switch in The GNU C Library Reference Manual ). Being extensible, the NSS supports plugins , which provide new name lookup implementations: for example, the nss-mdns plugin allow resolution of .local host names, the nis plugin allows user account lookup using the Network information service (NIS), and so on. These extra “lookup services” are configured system-wide in /etc/nsswitch.conf , and all the programs running on the system honor those settings (see NSS Configuration File in The GNU C Reference Manual ). When they perform a name lookup—for instance by calling the getaddrinfo function in C—applications first try to connect to the nscd; on success, nscd performs name lookups on their behalf. If the nscd is not running, then they perform the name lookup by themselves, by loading the name lookup services into their own address space and running it. These name lookup services—the libnss_*.so files—are dlopen 'd, but they may come from the host system's C library, rather than from the C library the application is linked against (the C library coming from Guix). And this is where the problem is: if your application is linked against Guix's C library (say, glibc 2.24) and tries to load NSS plugins from another C library (say, libnss_mdns.so for glibc 2.22), it will likely crash or have its name lookups fail unexpectedly. Running nscd on the system, among other advantages, eliminates this binary incompatibility problem because those libnss_*.so files are loaded in the nscd process, not in applications themselves. 2.6.3 X11 Fonts The majority of graphical applications use Fontconfig to locate and load fonts and perform X11-client-side rendering. The fontconfig package in Guix looks for fonts in $HOME/.guix-profile by default. Thus, to allow graphical applications installed with Guix to display fonts, you have to install fonts with Guix as well. Essential font packages include gs-fonts , font-dejavu , and font-gnu-freefont-ttf . To display text written in Chinese languages, Japanese, or Korean in graphical applications, consider installing font-adobe-source-han-sans or font-wqy-zenhei . The former has multiple outputs, one per language family (see 有多个输出的软件包 ). For instance, the following command installs fonts for Chinese languages: guix install font-adobe-source-han-sans:cn Older programs such as xterm do not use Fontconfig and instead rely on server-side font rendering. Such programs require to specify a full name of a font using XLFD (X Logical Font Description), like this: -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1 To be able to use such full names for the TrueType fonts installed in your Guix profile, you need to extend the font path of the X server: xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir)) After that, you can run xlsfonts (from xlsfonts package) to make sure your TrueType fonts are listed there. After installing fonts you may have to refresh the font cache to use them in applications. The same applies when applications installed via Guix do not seem to find fonts. To force rebuilding of the font cache run fc-cache -f . The fc-cache command is provided by the fontconfig package. 2.6.4 X.509证书 The nss-certs package provides X.509 certificates, which allow programs to authenticate Web servers accessed over HTTPS. When using Guix on a foreign distro, you can install this package and define the relevant environment variables so that packages know where to look for certificates. See X.509证书 , for detailed information. 2.6.5 Emacs Packages When you install Emacs packages with Guix, the elisp files may be placed either in $HOME/.guix-profile/share/emacs/site-lisp/ or in sub-directories of $HOME/.guix-profile/share/emacs/site-lisp/guix.d/ . The latter directory exists because potentially there may exist thousands of Emacs packages and storing all their files in a single directory may not be reliable (because of name conflicts). So we think using a separate directory for each package is a good idea. It is very similar to how the Emacs package system organizes the file structure (see Package Files in The GNU Emacs Manual ). By default, Emacs (installed with Guix) “knows” where these packages are placed, so you do not need to perform any configuration. If, for some reason, you want to avoid auto-loading Emacs packages installed with Guix, you can do so by running Emacs with --no-site-file option (see Init File in The GNU Emacs Manual ). 2.6.6 The GCC toolchain Guix offers individual compiler packages such as gcc but if you are in need of a complete toolchain for compiling and linking source code what you really want is the gcc-toolchain package. This package provides a complete GCC toolchain for C/C++ development, including GCC itself, the GNU C Library (headers and binaries, plus debugging symbols in the debug output), Binutils, and a linker wrapper. The wrapper's purpose is to inspect the -L and -l switches passed to the linker, add corresponding -rpath arguments, and invoke the actual linker with this new set of arguments. You can instruct the wrapper to refuse to link against libraries not in the store by setting the GUIX_LD_WRAPPER_ALLOW_IMPURITIES environment variable to no . Next: 软件包管理 , Previous: 安装 , Up: Top [ Contents ][ Index ] 3 系统安装 This section explains how to install Guix System on a machine. Guix, as a package manager, can also be installed on top of a running GNU/Linux system, see 安装 . • 限制 : 你可以期待什么。 • 硬件的考虑 : 支持的硬件。 • U盘和DVD安装 : 准备安装介质。 • 准备安装 : 网络、分区、等 • 指导的图形安装 : 简单的图形安装 • 手动安装 : 适合巫师的手动安装。 • 系统安装之后 : 当安装成功后。 • 在虚拟机里安装Guix。 : Guix系统游乐场。 • 构建安装镜像 : 这是怎样实现的。 Next: 硬件的考虑 , Up: 系统安装 [ Contents ][ Index ] 3.1 限制 We consider Guix System to be ready for a wide range of “desktop” and server use cases. The reliability guarantees it provides—transactional upgrades and rollbacks, reproducibility—make it a solid foundation. Nevertheless, before you proceed with the installation, be aware of the following noteworthy limitations applicable to version 1.0.1: Support for the Logical Volume Manager (LVM) is missing. More and more system services are provided (see 服务 ), but some may be missing. GNOME, Xfce, LXDE, and Enlightenment are available (see 桌面服务 ), as well as a number of X11 window managers. However, KDE is currently missing. More than a disclaimer, this is an invitation to report issues (and success stories!), and to join us in improving it. See 贡献 , for more info. Next: U盘和DVD安装 , Previous: 限制 , Up: 系统安装 [ Contents ][ Index ] 3.2 硬件的考虑 GNU Guix focuses on respecting the user's computing freedom. It builds around the kernel Linux-libre, which means that only hardware for which free software drivers and firmware exist is supported. Nowadays, a wide range of off-the-shelf hardware is supported on GNU/Linux-libre—from keyboards to graphics cards to scanners and Ethernet controllers. Unfortunately, there are still areas where hardware vendors deny users control over their own computing, and such hardware is not supported on Guix System. One of the main areas where free drivers or firmware are lacking is WiFi devices. WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the ath9k Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the b43-open Linux-libre driver. Free firmware exists for both and is available out-of-the-box on Guix System, as part of %base-firmware (see firmware ). The Free Software Foundation runs Respects Your Freedom (RYF), a certification program for hardware products that respect your freedom and your privacy and ensure that you have control over your device. We encourage you to check the list of RYF-certified devices. Another useful resource is the H-Node web site. It contains a catalog of hardware devices with information about their support in GNU/Linux. Next: 准备安装 , Previous: 硬件的考虑 , Up: 系统安装 [ Contents ][ Index ] 3.3 U盘和DVD安装 An ISO-9660 installation image that can be written to a USB stick or burnt to a DVD can be downloaded from ‘ https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1. system .iso.xz ', where system is one of: x86_64-linux for a GNU/Linux system on Intel/AMD-compatible 64-bit CPUs; i686-linux for a 32-bit GNU/Linux system on Intel-compatible CPUs. Make sure to download the associated .sig file and to verify the authenticity of the image against it, along these lines: $ wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1. 系统 .iso.xz.sig $ gpg --verify guix-system-install-1.0.1. 系统 .iso.xz.sig 如果那个命令因为缺少所需的公钥而失败了,那么用这个命令导入它: $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 再次运行 gpg --verify 命令。 This image contains the tools necessary for an installation. It is meant to be copied as is to a large-enough USB stick or DVD. Copying to a USB Stick To copy the image to a USB stick, follow these steps: Decompress the image using the xz command: xz -d guix-system-install-1.0.1. system .iso.xz Insert a USB stick of 1 GiB or more into your machine, and determine its device name. Assuming that the USB stick is known as /dev/sdX , copy the image with: dd if=guix-system-install-1.0.1. system .iso of=/dev/sdX sync Access to /dev/sdX usually requires root privileges. Burning on a DVD To copy the image to a DVD, follow these steps: Decompress the image using the xz command: xz -d guix-system-install-1.0.1. system .iso.xz Insert a blank DVD into your machine, and determine its device name. Assuming that the DVD drive is known as /dev/srX , copy the image with: growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.0.1. system .iso Access to /dev/srX usually requires root privileges. Booting Once this is done, you should be able to reboot the system and boot from the USB stick or DVD. The latter usually requires you to get in the BIOS or UEFI boot menu, where you can choose to boot from the USB stick. See 在虚拟机里安装Guix。 , if, instead, you would like to install Guix System in a virtual machine (VM). Next: 指导的图形安装 , Previous: U盘和DVD安装 , Up: 系统安装 [ Contents ][ Index ] 3.4 准备安装 Once you have booted, you can use the guided graphical installer, which makes it easy to get started (see 指导的图形安装 ). Alternately, if you are already familiar with GNU/Linux and if you want more control than what the graphical installer provides, you can choose the “manual” installation process (see 手动安装 ). The graphical installer is available on TTY1. You can obtain root shells on TTYs 3 to 6 by hitting ctrl-alt-f3 , ctrl-alt-f4 , etc. TTY2 shows this documentation and you can reach it with ctrl-alt-f2 . Documentation is browsable using the Info reader commands (see Stand-alone GNU Info ). The installation system runs the GPM mouse daemon, which allows you to select text with the left mouse button and to paste it with the middle button. 注: Installation requires access to the Internet so that any missing dependencies of your system configuration can be downloaded. See the “Networking” section below. Next: 手动安装 , Previous: 准备安装 , Up: 系统安装 [ Contents ][ Index ] 3.5 指导的图形安装 The graphical installer is a text-based user interface. It will guide you, with dialog boxes, through the steps needed to install GNU Guix System. The first dialog boxes allow you to set up the system as you use it during the installation: you can choose the language, keyboard layout, and set up networking, which will be used during the installation. The image below shows the networking dialog. Later steps allow you to partition your hard disk, as shown in the image below, to choose whether or not to use encrypted file systems, to enter the host name and root password, and to create an additional account, among other things. Note that, at any time, the installer allows you to exit the current installation step and resume at a previous step, as show in the image below. Once you're done, the installer produces an operating system configuration and displays it (see 使用配置系统 ). At that point you can hit “OK” and installation will proceed. On success, you can reboot into the new system and enjoy. See 系统安装之后 , for what's next! Next: 系统安装之后 , Previous: 指导的图形安装 , Up: 系统安装 [ Contents ][ Index ] 3.6 手动安装 This section describes how you would “manually” install GNU Guix System on your machine. This option requires familiarity with GNU/Linux, with the shell, and with common administration tools. If you think this is not for you, consider using the guided graphical installer (see 指导的图形安装 ). The installation system provides root shells on TTYs 3 to 6; press ctrl-alt-f3 , ctrl-alt-f4 , and so on to reach them. It includes many common tools needed to install the system. But it is also a full-blown Guix System, which means that you can install additional packages, should you need it, using guix package (see 调用guix package ). • 键盘布局、网络和分区 : 初始设置。 • 继续安装步骤。 : 安装。 Next: 继续安装步骤。 , Up: 手动安装 [ Contents ][ Index ] 3.6.1 Keyboard Layout, Networking, and Partitioning Before you can install the system, you may want to adjust the keyboard layout, set up networking, and partition your target hard disk. This section will guide you through this. 3.6.1.1 键盘布局 The installation image uses the US qwerty keyboard layout. If you want to change it, you can use the loadkeys command. For example, the following command selects the Dvorak keyboard layout: loadkeys dvorak See the files under /run/current-system/profile/share/keymaps for a list of available keyboard layouts. Run man loadkeys for more information. 3.6.1.2 Networking Run the following command to see what your network interfaces are called: ifconfig -a … or, using the GNU/Linux-specific ip command: ip a Wired interfaces have a name starting with ‘ e '; for example, the interface corresponding to the first on-board Ethernet controller is called ‘ eno1 '. Wireless interfaces have a name starting with ‘ w ', like ‘ w1p2s0 '. Wired connection To configure a wired network run the following command, substituting interface with the name of the wired interface you want to use. ifconfig interface up Wireless connection To configure wireless networking, you can create a configuration file for the wpa_supplicant configuration tool (its location is not important) using one of the available text editors such as nano : nano wpa_supplicant.conf As an example, the following stanza can go to this file and will work for many wireless networks, provided you give the actual SSID and passphrase for the network you are connecting to: network={ ssid=" my-ssid " key_mgmt=WPA-PSK psk="the network's secret passphrase" } Start the wireless service and run it in the background with the following command (substitute interface with the name of the network interface you want to use): wpa_supplicant -c wpa_supplicant.conf -i interface -B Run man wpa_supplicant for more information. At this point, you need to acquire an IP address. On a network where IP addresses are automatically assigned via DHCP, you can run: dhclient -v interface Try to ping a server to see if networking is up and running: ping -c 3 gnu.org Setting up network access is almost always a requirement because the image does not contain all the software and tools that may be needed. If you want to, you can continue the installation remotely by starting an SSH server: herd start ssh-daemon Make sure to either set a password with passwd , or configure OpenSSH public key authentication before logging in. 3.6.1.3 Disk Partitioning Unless this has already been done, the next step is to partition, and then format the target partition(s). The installation image includes several partitioning tools, including Parted (see Overview in GNU Parted User Manual ), fdisk , and cfdisk . Run it and set up your disk with the partition layout you want: cfdisk If your disk uses the GUID Partition Table (GPT) format and you plan to install BIOS-based GRUB (which is the default), make sure a BIOS Boot Partition is available (see BIOS installation in GNU GRUB manual ). If you instead wish to use EFI-based GRUB, a FAT32 EFI System Partition (ESP) is required. This partition can be mounted at /boot/efi for instance and must have the esp flag set. E.g., for parted : parted /dev/sda set 1 esp on 注: Unsure whether to use EFI- or BIOS-based GRUB? If the directory /sys/firmware/efi exists in the installation image, then you should probably perform an EFI installation, using grub-efi-bootloader . Otherwise you should use the BIOS-based GRUB, known as grub-bootloader . See 引导设置 , for more info on bootloaders. Once you are done partitioning the target hard disk drive, you have to create a file system on the relevant partition(s) 8 . For the ESP, if you have one and assuming it is /dev/sda1 , run: mkfs.fat -F32 /dev/sda1 Preferably, assign file systems a label so that you can easily and reliably refer to them in file-system declarations (see 文件系统 ). This is typically done using the -L option of mkfs.ext4 and related commands. So, assuming the target root partition lives at /dev/sda2 , a file system with the label my-root can be created with: mkfs.ext4 -L my-root /dev/sda2 If you are instead planning to encrypt the root partition, you can use the Cryptsetup/LUKS utilities to do that (see man cryptsetup for more information.) Assuming you want to store the root partition on /dev/sda2 , the command sequence would be along these lines: cryptsetup luksFormat /dev/sda2 cryptsetup open --type luks /dev/sda2 my-partition mkfs.ext4 -L my-root /dev/mapper/my-partition Once that is done, mount the target file system under /mnt with a command like (again, assuming my-root is the label of the root file system): mount LABEL=my-root /mnt Also mount any other file systems you would like to use on the target system relative to this path. If you have opted for /boot/efi as an EFI mount point for example, mount it at /mnt/boot/efi now so it is found by guix system init afterwards. Finally, if you plan to use one or more swap partitions (see swap space in The GNU C Library Reference Manual ), make sure to initialize them with mkswap . Assuming you have one swap partition on /dev/sda3 , you would run: mkswap /dev/sda3 swapon /dev/sda3 Alternatively, you may use a swap file. For example, assuming that in the new system you want to use the file /swapfile as a swap file, you would run 9 : # This is 10 GiB of swap space. Adjust "count" to change the size. dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240 # For security, make the file readable and writable only by root. chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile Note that if you have encrypted the root partition and created a swap file in its file system as described above, then the encryption also protects the swap file, just like any other file in that file system. Previous: 键盘布局、网络和分区 , Up: 手动安装 [ Contents ][ Index ] 3.6.2 继续安装步骤。 With the target partitions ready and the target root mounted on /mnt , we're ready to go. First, run: herd start cow-store /mnt This makes /gnu/store copy-on-write, such that packages added to it during the installation phase are written to the target disk on /mnt rather than kept in memory. This is necessary because the first phase of the guix system init command (see below) entails downloads or builds to /gnu/store which, initially, is an in-memory file system. Next, you have to edit a file and provide the declaration of the operating system to be installed. To that end, the installation system comes with three text editors. We recommend GNU nano (see GNU nano Manual ), which supports syntax highlighting and parentheses matching; other editors include GNU Zile (an Emacs clone), and nvi (a clone of the original BSD vi editor). We strongly recommend storing that file on the target root file system, say, as /mnt/etc/config.scm . Failing to do that, you will have lost your configuration file once you have rebooted into the newly-installed system. See 使用配置系统 , for an overview of the configuration file. The example configurations discussed in that section are available under /etc/configuration in the installation image. Thus, to get started with a system configuration providing a graphical display server (a “desktop” system), you can run something along these lines: # mkdir /mnt/etc # cp /etc/configuration/desktop.scm /mnt/etc/config.scm # nano /mnt/etc/config.scm You should pay attention to what your configuration file contains, and in particular: Make sure the bootloader-configuration form refers to the target you want to install GRUB on. It should mention grub-bootloader if you are installing GRUB in the legacy way, or grub-efi-bootloader for newer UEFI systems. For legacy systems, the target field names a device, like /dev/sda ; for UEFI systems it names a path to a mounted EFI partition, like /boot/efi ; do make sure the path is currently mounted and a file-system entry is specified in your configuration. Be sure that your file system labels match the value of their respective device fields in your file-system configuration, assuming your file-system configuration uses the file-system-label procedure in its device field. If there are encrypted or RAID partitions, make sure to add a mapped-devices field to describe them (see 映射的设备 ). Once you are done preparing the configuration file, the new system must be initialized (remember that the target root file system is mounted under /mnt ): guix system init /mnt/etc/config.scm /mnt This copies all the necessary files and installs GRUB on /dev/sdX , unless you pass the --no-bootloader option. For more information, see 调用guix system . This command may trigger downloads or builds of missing packages, which can take some time. Once that command has completed—and hopefully succeeded!—you can run reboot and boot into the new system. The root password in the new system is initially empty; other users' passwords need to be initialized by running the passwd command as root , unless your configuration specifies otherwise (see user account passwords ). See 系统安装之后 , for what's next! Next: 在虚拟机里安装Guix。 , Previous: 手动安装 , Up: 系统安装 [ Contents ][ Index ] 3.7 系统安装之后 Success, you've now booted into Guix System! From then on, you can update the system whenever you want by running, say: guix pull sudo guix system reconfigure /etc/config.scm This builds a new system generation with the latest packages and services (see 调用guix system ). We recommend doing that regularly so that your system includes the latest security updates (see 安全更新 ). 注: Note that sudo guix runs your user's guix command and not root's, because sudo leaves PATH unchanged. To explicitly run root's guix , type sudo -i guix … . Join us on #guix on the Freenode IRC network or on guix-devel@gnu.org to share your experience! Next: 构建安装镜像 , Previous: 系统安装之后 , Up: 系统安装 [ Contents ][ Index ] 3.8 Installing Guix in a Virtual Machine If you'd like to install Guix System in a virtual machine (VM) or on a virtual private server (VPS) rather than on your beloved machine, this section is for you. To boot a QEMU VM for installing Guix System in a disk image, follow these steps: First, retrieve and decompress the Guix system installation image as described previously (see U盘和DVD安装 ). Create a disk image that will hold the installed system. To make a qcow2-formatted disk image, use the qemu-img command: qemu-img create -f qcow2 guixsd.img 50G The resulting file will be much smaller than 50 GB (typically less than 1 MB), but it will grow as the virtualized storage device is filled up. Boot the USB installation image in an VM: qemu-system-x86_64 -m 1024 -smp 1 \ -net user -net nic,model=virtio -boot menu=on \ -drive file=guix-system-install-1.0.1. system .iso \ -drive file=guixsd.img The ordering of the drives matters. In the VM console, quickly press the F12 key to enter the boot menu. Then press the 2 key and the RET key to validate your selection. You're now root in the VM, proceed with the installation process. See 准备安装 , and follow the instructions. Once installation is complete, you can boot the system that's on your guixsd.img image. See 在虚拟机里运行Guix , for how to do that. Previous: 在虚拟机里安装Guix。 , Up: 系统安装 [ Contents ][ Index ] 3.9 构建安装镜像 The installation image described above was built using the guix system command, specifically: guix system disk-image --file-system-type=iso9660 \ gnu/system/install.scm Have a look at gnu/system/install.scm in the source tree, and see also 调用guix system for more information about the installation image. 3.10 Building the Installation Image for ARM Boards Many ARM boards require a specific variant of the U-Boot bootloader. If you build a disk image and the bootloader is not available otherwise (on another boot drive etc), it's advisable to build an image that includes the bootloader, specifically: guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' A20-OLinuXino-Lime2 is the name of the board. If you specify an invalid board, a list of possible boards will be printed. Next: 开发 , Previous: 系统安装 , Up: Top [ Contents ][ Index ] 4 软件包管理 The purpose of GNU Guix is to allow users to easily install, upgrade, and remove software packages, without having to know about their build procedures or dependencies. Guix also goes beyond this obvious set of features. This chapter describes the main features of Guix, as well as the package management tools it provides. Along with the command-line interface described below (see guix package ), you may also use the Emacs-Guix interface (see The Emacs-Guix Reference Manual ), after installing emacs-guix package (run M-x guix-help command to start with it): guix install emacs-guix • 功能 : Guix怎样让你的生活更美好。 • 调用guix package : 软件包安装,删除,等 • Substitutes : 下载构建好的二进制文件。 • 有多个输出的软件包 : 单个输入多个输出的软件包。 • 调用guix gc : 运行垃圾回收器。 • 调用guix pull : 获取最新的Guix和发行版。 • 通道 : 定制软件包集合。 • Inferiors : 和其它版本的Guix交互。 • 调用guix describe : 显示你的Guix版本信息。 • 调用guix archive : 导出和导入仓库文件。 Next: 调用guix package , Up: 软件包管理 [ Contents ][ Index ] 4.1 功能 When using Guix, each package ends up in the package store , in its own directory—something that resembles /gnu/store/xxx-package-1.2 , where xxx is a base32 string. Instead of referring to these directories, users have their own profile , which points to the packages that they actually want to use. These profiles are stored within each user's home directory, at $HOME/.guix-profile . For example, alice installs GCC 4.7.2. As a result, /home/alice/.guix-profile/bin/gcc points to /gnu/store/…-gcc-4.7.2/bin/gcc . Now, on the same machine, bob had already installed GCC 4.8.0. The profile of bob simply continues to point to /gnu/store/…-gcc-4.8.0/bin/gcc —i.e., both versions of GCC coexist on the same system without any interference. The guix package command is the central tool to manage packages (see 调用guix package ). It operates on the per-user profiles, and can be used with normal user privileges . The command provides the obvious install, remove, and upgrade operations. Each invocation is actually a transaction : either the specified operation succeeds, or nothing happens. Thus, if the guix package process is terminated during the transaction, or if a power outage occurs during the transaction, then the user's profile remains in its previous state, and remains usable. In addition, any package transaction may be rolled back . So, if, for example, an upgrade installs a new version of a package that turns out to have a serious bug, users may roll back to the previous instance of their profile, which was known to work well. Similarly, the global system configuration on Guix is subject to transactional upgrades and roll-back (see 使用配置系统 ). All packages in the package store may be garbage-collected . Guix can determine which packages are still referenced by user profiles, and remove those that are provably no longer referenced (see 调用guix gc ). Users may also explicitly remove old generations of their profile so that the packages they refer to can be collected. Guix takes a purely functional approach to package management, as described in the introduction (see 介绍 ). Each /gnu/store package directory name contains a hash of all the inputs that were used to build that package—compiler, libraries, build scripts, etc. This direct correspondence allows users to make sure a given package installation matches the current state of their distribution. It also helps maximize build reproducibility : thanks to the isolated build environments that are used, a given build is likely to yield bit-identical files when performed on different machines (see container ). This foundation allows Guix to support transparent binary/source deployment . When a pre-built binary for a /gnu/store item is available from an external source—a substitute , Guix just downloads it and unpacks it; otherwise, it builds the package from source, locally (see Substitutes ). Because build results are usually bit-for-bit reproducible, users do not have to trust servers that provide substitutes: they can force a local build and challenge providers (see 调用guix challenge ). Control over the build environment is a feature that is also useful for developers. The guix environment command allows developers of a package to quickly set up the right development environment for their package, without having to manually install the dependencies of the package into their profile (see 调用guix environment ). All of Guix and its package definitions is version-controlled, and guix pull allows you to “travel in time” on the history of Guix itself (see 调用guix pull ). This makes it possible to replicate a Guix instance on a different machine or at a later point in time, which in turn allows you to replicate complete software environments , while retaining precise provenance tracking of the software. Next: Substitutes , Previous: 功能 , Up: 软件包管理 [ Contents ][ Index ] 4.2 Invoking guix package The guix package command is the tool that allows users to install, upgrade, and remove packages, as well as rolling back to previous configurations. It operates only on the user's own profile, and works with normal user privileges (see 功能 ). Its syntax is: guix package options Primarily, options specifies the operations to be performed during the transaction. Upon completion, a new profile is created, but previous generations of the profile remain available, should the user want to roll back. For example, to remove lua and install guile and guile-cairo in a single transaction: guix package -r lua -i guile guile-cairo For your convenience, we also provide the following aliases: guix search is an alias for guix package -s , guix install is an alias for guix package -i , guix remove is an alias for guix package -r , and guix upgrade is an alias for guix package -u . These aliases are less expressive than guix package and provide fewer options, so in some cases you'll probably want to use guix package directly. guix package also supports a declarative approach whereby the user specifies the exact set of packages to be available and passes it via the --manifest option (see --manifest ). For each user, a symlink to the user's default profile is automatically created in $HOME/.guix-profile . This symlink always points to the current generation of the user's default profile. Thus, users can add $HOME/.guix-profile/bin to their PATH environment variable, and so on. If you are not using Guix System, consider adding the following lines to your ~/.bash_profile (see Bash Startup Files in The GNU Bash Reference Manual ) so that newly-spawned shells get all the right environment variable definitions: GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" In a multi-user setup, user profiles are stored in a place registered as a garbage-collector root , which $HOME/.guix-profile points to (see 调用guix gc ). That directory is normally localstatedir /guix/profiles/per-user/ user , where localstatedir is the value passed to configure as --localstatedir , and user is the user name. The per-user directory is created when guix-daemon is started, and the user sub-directory is created by guix package . The options can be among the following: --install= package … -i package … Install the specified package s. Each package may specify either a simple package name, such as guile , or a package name followed by an at-sign and version number, such as guile@1.8.8 or simply guile@1.8 (in the latter case, the newest version prefixed by 1.8 is selected.) If no version number is specified, the newest available version will be selected. In addition, package may contain a colon, followed by the name of one of the outputs of the package, as in gcc:doc or binutils@2.22:lib (see 有多个输出的软件包 ). Packages with a corresponding name (and optionally version) are searched for among the GNU distribution modules (see 软件包模块 ). Sometimes packages have propagated inputs : these are dependencies that automatically get installed along with the required package (see propagated-inputs in package objects , for information about propagated inputs in package definitions). An example is the GNU MPC library: its C header files refer to those of the GNU MPFR library, which in turn refer to those of the GMP library. Thus, when installing MPC, the MPFR and GMP libraries also get installed in the profile; removing MPC also removes MPFR and GMP—unless they had also been explicitly installed by the user. Besides, packages sometimes rely on the definition of environment variables for their search paths (see explanation of --search-paths below). Any missing or possibly incorrect environment variable definitions are reported here. --install-from-expression= exp -e exp Install the package exp evaluates to. exp must be a Scheme expression that evaluates to a <package> object. This option is notably useful to disambiguate between same-named variants of a package, with expressions such as (@ (gnu packages base) guile-final) . Note that this option installs the first output of the specified package, which may be insufficient when needing a specific output of a multiple-output package. --install-from-file= file -f file Install the package that the code within file evaluates to. As an example, file might contain a definition like this (see 定义软件包 ): (use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+)) Developers may find it useful to include such a guix.scm file in the root of their project source tree that can be used to test development snapshots and create reproducible development environments (see 调用guix environment ). --remove= package … -r package … Remove the specified package s. As for --install , each package may specify a version number and/or output name in addition to the package name. For instance, -r glibc:debug would remove the debug output of glibc . --upgrade[= regexp …] -u [ regexp …] Upgrade all the installed packages. If one or more regexp s are specified, upgrade only installed packages whose name matches a regexp . Also see the --do-not-upgrade option below. Note that this upgrades package to the latest version of packages found in the distribution currently installed. To update your distribution, you should regularly run guix pull (see 调用guix pull ). --do-not-upgrade[= regexp …] When used together with the --upgrade option, do not upgrade any packages whose name matches a regexp . For example, to upgrade all packages in the current profile except those containing the substring “emacs”: $ guix package --upgrade . --do-not-upgrade emacs --manifest= file -m file Create a new generation of the profile from the manifest object returned by the Scheme code in file . This allows you to declare the profile's contents rather than constructing it through a sequence of --install and similar commands. The advantage is that file can be put under version control, copied to different machines to reproduce the same profile, and so on. file must return a manifest object, which is roughly a list of packages: (use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Use a specific package output. (list guile-2.0 "debug"))) In this example we have to know which modules define the emacs and guile-2.0 variables to provide the right use-package-modules line, which can be cumbersome. We can instead provide regular package specifications and let specifications->manifest look up the corresponding package objects, like this: (specifications->manifest '("emacs" "guile@2.2" "guile@2.2:debug")) --roll-back Roll back to the previous generation of the profile—i.e., undo the last transaction. When combined with options such as --install , roll back occurs before any other actions. When rolling back from the first generation that actually contains installed packages, the profile is made to point to the zeroth generation , which contains no files apart from its own metadata. After having rolled back, installing, removing, or upgrading packages overwrites previous future generations. Thus, the history of the generations in a profile is always linear. --switch-generation= pattern -S pattern Switch to a particular generation defined by pattern . pattern may be either a generation number or a number prefixed with “+” or “-”. The latter means: move forward/backward by a specified number of generations. For example, if you want to return to the latest generation after --roll-back , use --switch-generation=+1 . The difference between --roll-back and --switch-generation=-1 is that --switch-generation will not make a zeroth generation, so if a specified generation does not exist, the current generation will not be changed. --search-paths[= kind ] Report environment variable definitions, in Bash syntax, that may be needed in order to use the set of installed packages. These environment variables are used to specify search paths for files used by some of the installed packages. For example, GCC needs the CPATH and LIBRARY_PATH environment variables to be defined so it can look for headers and libraries in the user's profile (see Environment Variables in Using the GNU Compiler Collection (GCC) ). If GCC and, say, the C library are installed in the profile, then --search-paths will suggest setting these variables to profile /include and profile /lib , respectively. The typical use case is to define these environment variables in the shell: $ eval `guix package --search-paths` kind may be one of exact , prefix , or suffix , meaning that the returned environment variable definitions will either be exact settings, or prefixes or suffixes of the current value of these variables. When omitted, kind defaults to exact . This option can also be used to compute the combined search paths of several profiles. Consider this example: $ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths The last command above reports about the GUILE_LOAD_PATH variable, even though, taken individually, neither foo nor bar would lead to that recommendation. --profile= profile -p profile Use profile instead of the user's default profile. --allow-collisions Allow colliding packages in the new profile. Use at your own risk! By default, guix package reports as an error collisions in the profile. Collisions happen when two or more different versions or variants of a given package end up in the profile. --bootstrap Use the bootstrap Guile to build the profile. This option is only useful to distribution developers. In addition to these actions, guix package supports the following options to query the current state of a profile, or the availability of packages: --search= regexp -s regexp List the available packages whose name, synopsis, or description matches regexp (in a case-insensitive fashion), sorted by relevance. Print all the metadata of matching packages in recutils format (see GNU recutils databases in GNU recutils manual ). This allows specific fields to be extracted using the recsel command, for instance: $ guix package -s malloc | recsel -p name,version,relevance name: jemalloc version: 4.5.0 relevance: 6 name: glibc version: 2.25 relevance: 1 name: libgc version: 7.6.0 relevance: 1 Similarly, to show the name of all the packages available under the terms of the GNU LGPL version 3: $ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"' name: elfutils name: gmp … It is also possible to refine search results using several -s flags to guix package , or several arguments to guix search . For example, the following command returns a list of board games (this time using the guix search alias): $ guix search '\<board\>' game | recsel -p name name: gnubg … If we were to omit -s game , we would also get software packages that deal with printed circuit boards; removing the angle brackets around board would further add packages that have to do with keyboards. And now for a more elaborate example. The following command searches for cryptographic libraries, filters out Haskell, Perl, Python, and Ruby libraries, and prints the name and synopsis of the matching packages: $ guix search crypto library | \ recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis See Selection Expressions in GNU recutils manual , for more information on selection expressions for recsel -e . --show= package Show details about package , taken from the list of available packages, in recutils format (see GNU recutils databases in GNU recutils manual ). $ guix package --show=python | recsel -p name,version name: python version: 2.7.6 name: python version: 3.3.5 You may also specify the full name of a package to only get details about a specific version of it: $ guix package --show=python@3.4 | recsel -p name,version name: python version: 3.4.3 --list-installed[= regexp ] -I [ regexp ] List the currently installed packages in the specified profile, with the most recently installed packages shown last. When regexp is specified, list only installed packages whose name matches regexp . For each installed package, print the following items, separated by tabs: the package name, its version string, the part of the package that is installed (for instance, out for the default output, include for its headers, etc.), and the path of this package in the store. --list-available[= regexp ] -A [ regexp ] List packages currently available in the distribution for this system (see GNU发行版 ). When regexp is specified, list only installed packages whose name matches regexp . For each package, print the following items separated by tabs: its name, its version string, the parts of the package (see 有多个输出的软件包 ), and the source location of its definition. --list-generations[= pattern ] -l [ pattern ] Return a list of generations along with their creation dates; for each generation, show the installed packages, with the most recently installed packages shown last. Note that the zeroth generation is never shown. For each installed package, print the following items, separated by tabs: the name of a package, its version string, the part of the package that is installed (see 有多个输出的软件包 ), and the location of this package in the store. When pattern is used, the command returns only matching generations. Valid patterns include: Integers and comma-separated integers . Both patterns denote generation numbers. For instance, --list-generations=1 returns the first one. And --list-generations=1,8,2 outputs three generations in the specified order. Neither spaces nor trailing commas are allowed. Ranges . --list-generations=2..9 prints the specified generations and everything in between. Note that the start of a range must be smaller than its end. It is also possible to omit the endpoint. For example, --list-generations=2.. , returns all generations starting from the second one. Durations . You can also get the last N days, weeks, or months by passing an integer along with the first letter of the duration. For example, --list-generations=20d lists generations that are up to 20 days old. --delete-generations[= pattern ] -d [ pattern ] When pattern is omitted, delete all generations except the current one. This command accepts the same patterns as --list-generations . When pattern is specified, delete the matching generations. When pattern specifies a duration, generations older than the specified duration match. For instance, --delete-generations=1m deletes generations that are more than one month old. If the current generation matches, it is not deleted. Also, the zeroth generation is never deleted. Note that deleting generations prevents rolling back to them. Consequently, this command must be used with care. Finally, since guix package may actually start build processes, it supports all the common build options (see 普通的构建选项 ). It also supports package transformation options, such as --with-source (see 软件包变换选项。 ). However, note that package transformations are lost when upgrading; to preserve transformations across upgrades, you should define your own package variant in a Guile module and add it to GUIX_PACKAGE_PATH (see 定义软件包 ). Next: 有多个输出的软件包 , Previous: 调用guix package , Up: 软件包管理 [ Contents ][ Index ] 4.3 Substitutes Guix supports transparent source/binary deployment, which means that it can either build things locally, or download pre-built items from a server, or both. We call these pre-built items substitutes —they are substitutes for local build results. In many cases, downloading a substitute is much faster than building things locally. Substitutes can be anything resulting from a derivation build (see Derivations ). Of course, in the common case, they are pre-built package binaries, but source tarballs, for instance, which also result from derivation builds, can be available as substitutes. • 官方的substitute服务器 : substitute的一个特殊来源。 • 授权substitute服务器。 : 怎么开启或关闭substitute。 • 验证substitute : Guix怎样验证substitute。 • 代理设置 : 怎样通过代理获取substitute。 • substitute失败 : 当substitute失败时会发生什么。 • 关于信任二进制文件 : 你怎么信任二进制块。 Next: 授权substitute服务器。 , Up: Substitutes [ Contents ][ Index ] 4.3.1 官方的substitute服务器 The ci.guix.gnu.org server is a front-end to an official build farm that builds packages from Guix continuously for some architectures, and makes them available as substitutes. This is the default source of substitutes; it can be overridden by passing the --substitute-urls option either to guix-daemon (see guix-daemon --substitute-urls ) or to client tools such as guix package (see client --substitute-urls option ). Substitute URLs can be either HTTP or HTTPS. HTTPS is recommended because communications are encrypted; conversely, using HTTP makes all communications visible to an eavesdropper, who could use the information gathered to determine, for instance, whether your system has unpatched security vulnerabilities. Substitutes from the official build farm are enabled by default when using Guix System (see GNU发行版 ). However, they are disabled by default when using Guix on a foreign distribution, unless you have explicitly enabled them via one of the recommended installation steps (see 安装 ). The following paragraphs describe how to enable or disable substitutes for the official build farm; the same procedure can also be used to enable substitutes for any other substitute server. Next: 验证substitute , Previous: 官方的substitute服务器 , Up: Substitutes [ Contents ][ Index ] 4.3.2 授权substitute服务器。 To allow Guix to download substitutes from ci.guix.gnu.org or a mirror thereof, you must add its public key to the access control list (ACL) of archive imports, using the guix archive command (see 调用guix archive ). Doing so implies that you trust ci.guix.gnu.org to not be compromised and to serve genuine substitutes. The public key for ci.guix.gnu.org is installed along with Guix, in prefix /share/guix/ci.guix.gnu.org.pub , where prefix is the installation prefix of Guix. If you installed Guix from source, make sure you checked the GPG signature of guix-1.0.1.tar.gz , which contains this public key file. Then, you can run something like this: # guix archive --authorize < prefix /share/guix/ci.guix.gnu.org.pub 注: Similarly, the hydra.gnu.org.pub file contains the public key of an independent build farm also run by the project, reachable at ‘ https://mirror.hydra.gnu.org '. Once this is in place, the output of a command like guix build should change from something like: $ guix build emacs --dry-run The following derivations would be built: /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv … to something like: $ guix build emacs --dry-run 112.3 MB would be downloaded: /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3 /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16 /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7 … This indicates that substitutes from ci.guix.gnu.org are usable and will be downloaded, when possible, for future builds. The substitute mechanism can be disabled globally by running guix-daemon with --no-substitutes (see 调用guix-daemon ). It can also be disabled temporarily by passing the --no-substitutes option to guix package , guix build , and other command-line tools. Next: 代理设置 , Previous: 授权substitute服务器。 , Up: Substitutes [ Contents ][ Index ] 4.3.3 验证substitute Guix detects and raises an error when attempting to use a substitute that has been tampered with. Likewise, it ignores substitutes that are not signed, or that are not signed by one of the keys listed in the ACL. There is one exception though: if an unauthorized server provides substitutes that are bit-for-bit identical to those provided by an authorized server, then the unauthorized server becomes eligible for downloads. For example, assume we have chosen two substitute servers with this option: --substitute-urls="https://a.example.org https://b.example.org" If the ACL contains only the key for b.example.org , and if a.example.org happens to serve the exact same substitutes, then Guix will download substitutes from a.example.org because it comes first in the list and can be considered a mirror of b.example.org . In practice, independent build machines usually produce the same binaries, thanks to bit-reproducible builds (see below). When using HTTPS, the server's X.509 certificate is not validated (in other words, the server is not authenticated), contrary to what HTTPS clients such as Web browsers usually do. This is because Guix authenticates substitute information itself, as explained above, which is what we care about (whereas X.509 certificates are about authenticating bindings between domain names and public keys.) Next: substitute失败 , Previous: 验证substitute , Up: Substitutes [ Contents ][ Index ] 4.3.4 代理设置 Substitutes are downloaded over HTTP or HTTPS. The http_proxy environment variable can be set in the environment of guix-daemon and is honored for downloads of substitutes. Note that the value of http_proxy in the environment where guix build , guix package , and other client commands are run has absolutely no effect . Next: 关于信任二进制文件 , Previous: 代理设置 , Up: Substitutes [ Contents ][ Index ] 4.3.5 substitute失败 Even when a substitute for a derivation is available, sometimes the substitution attempt will fail. This can happen for a variety of reasons: the substitute server might be offline, the substitute may recently have been deleted, the connection might have been interrupted, etc. When substitutes are enabled and a substitute for a derivation is available, but the substitution attempt fails, Guix will attempt to build the derivation locally depending on whether or not --fallback was given (see common build option --fallback ). Specifically, if --fallback was omitted, then no local build will be performed, and the derivation is considered to have failed. However, if --fallback was given, then Guix will attempt to build the derivation locally, and the success or failure of the derivation depends on the success or failure of the local build. Note that when substitutes are disabled or no substitute is available for the derivation in question, a local build will always be performed, regardless of whether or not --fallback was given. To get an idea of how many substitutes are available right now, you can try running the guix weather command (see 调用guix weather ). This command provides statistics on the substitutes provided by a server. Previous: substitute失败 , Up: Substitutes [ Contents ][ Index ] 4.3.6 关于信任二进制文件 Today, each individual's control over their own computing is at the mercy of institutions, corporations, and groups with enough power and determination to subvert the computing infrastructure and exploit its weaknesses. While using ci.guix.gnu.org substitutes can be convenient, we encourage users to also build on their own, or even run their own build farm, such that ci.guix.gnu.org is less of an interesting target. One way to help is by publishing the software you build using guix publish so that others have one more choice of server to download substitutes from (see 调用guix publish ). Guix has the foundations to maximize build reproducibility (see 功能 ). In most cases, independent builds of a given package or derivation should yield bit-identical results. Thus, through a diverse set of independent package builds, we can strengthen the integrity of our systems. The guix challenge command aims to help users assess substitute servers, and to assist developers in finding out about non-deterministic package builds (see 调用guix challenge ). Similarly, the --check option of guix build allows users to check whether previously-installed substitutes are genuine by rebuilding them locally (see guix build --check ). In the future, we want Guix to have support to publish and retrieve binaries to/from other users, in a peer-to-peer fashion. If you would like to discuss this project, join us on guix-devel@gnu.org . Next: 调用guix gc , Previous: Substitutes , Up: 软件包管理 [ Contents ][ Index ] 4.4 有多个输出的软件包 Often, packages defined in Guix have a single output —i.e., the source package leads to exactly one directory in the store. When running guix install glibc , one installs the default output of the GNU libc package; the default output is called out , but its name can be omitted as shown in this command. In this particular case, the default output of glibc contains all the C header files, shared libraries, static libraries, Info documentation, and other supporting files. Sometimes it is more appropriate to separate the various types of files produced from a single source package into separate outputs. For instance, the GLib C library (used by GTK+ and related packages) installs more than 20 MiB of reference documentation as HTML pages. To save space for users who do not need it, the documentation goes to a separate output, called doc . To install the main GLib output, which contains everything but the documentation, one would run: guix install glib The command to install its documentation is: guix install glib:doc Some packages install programs with different “dependency footprints”. For instance, the WordNet package installs both command-line tools and graphical user interfaces (GUIs). The former depend solely on the C library, whereas the latter depend on Tcl/Tk and the underlying X libraries. In this case, we leave the command-line tools in the default output, whereas the GUIs are in a separate output. This allows users who do not need the GUIs to save space. The guix size command can help find out about such situations (see 调用guix size ). guix graph can also be helpful (see 调用guix graph ). There are several such multiple-output packages in the GNU distribution. Other conventional output names include lib for libraries and possibly header files, bin for stand-alone programs, and debug for debugging information (see 安装调试文件 ). The outputs of a packages are listed in the third column of the output of guix package --list-available (see 调用guix package ). Next: 调用guix pull , Previous: 有多个输出的软件包 , Up: 软件包管理 [ Contents ][ Index ] 4.5 Invoking guix gc Packages that are installed, but not used, may be garbage-collected . The guix gc command allows users to explicitly run the garbage collector to reclaim space from the /gnu/store directory. It is the only way to remove files from /gnu/store —removing files or directories manually may break it beyond repair! The garbage collector has a set of known roots : any file under /gnu/store reachable from a root is considered live and cannot be deleted; any other file is considered dead and may be deleted. The set of garbage collector roots (“GC roots” for short) includes default user profiles; by default, the symlinks under /var/guix/gcroots represent these GC roots. New GC roots can be added with guix build --root , for example (see 调用guix build ). The guix gc --list-roots command lists them. Prior to running guix gc --collect-garbage to make space, it is often useful to remove old generations from user profiles; that way, old package builds referenced by those generations can be reclaimed. This is achieved by running guix package --delete-generations (see 调用guix package ). Our recommendation is to run a garbage collection periodically, or when you are short on disk space. For instance, to guarantee that at least 5 GB are available on your disk, simply run: guix gc -F 5G It is perfectly safe to run as a non-interactive periodic job (see 执行计划任务 , for how to set up such a job). Running guix gc with no arguments will collect as much garbage as it can, but that is often inconvenient: you may find yourself having to rebuild or re-download software that is “dead” from the GC viewpoint but that is necessary to build other pieces of software—e.g., the compiler tool chain. The guix gc command has three modes of operation: it can be used to garbage-collect any dead files (the default), to delete specific files (the --delete option), to print garbage-collector information, or for more advanced queries. The garbage collection options are as follows: --collect-garbage[= min ] -C [ min ] Collect garbage—i.e., unreachable /gnu/store files and sub-directories. This is the default operation when no option is specified. When min is given, stop once min bytes have been collected. min may be a number of bytes, or it may include a unit as a suffix, such as MiB for mebibytes and GB for gigabytes (see size specifications in GNU Coreutils ). When min is omitted, collect all the garbage. --free-space= free -F free Collect garbage until free space is available under /gnu/store , if possible; free denotes storage space, such as 500MiB , as described above. When free or more is already available in /gnu/store , do nothing and exit immediately. --delete-generations[= duration ] -d [ duration ] Before starting the garbage collection process, delete all the generations older than duration , for all the user profiles; when run as root, this applies to all the profiles of all the users . For example, this command deletes all the generations of all your profiles that are older than 2 months (except generations that are current), and then proceeds to free space until at least 10 GiB are available: guix gc -d 2m -F 10G --delete -D Attempt to delete all the store files and directories specified as arguments. This fails if some of the files are not in the store, or if they are still live. --list-failures List store items corresponding to cached build failures. This prints nothing unless the daemon was started with --cache-failures (see --cache-failures ). --list-roots List the GC roots owned by the user; when run as root, list all the GC roots. --clear-failures Remove the specified store items from the failed-build cache. Again, this option only makes sense when the daemon is started with --cache-failures . Otherwise, it does nothing. --list-dead Show the list of dead files and directories still present in the store—i.e., files and directories no longer reachable from any root. --list-live Show the list of live store files and directories. In addition, the references among existing store files can be queried: --references --referrers List the references (respectively, the referrers) of store files given as arguments. --requisites -R List the requisites of the store files passed as arguments. Requisites include the store files themselves, their references, and the references of these, recursively. In other words, the returned list is the transitive closure of the store files. See 调用guix size , for a tool to profile the size of the closure of an element. See 调用guix graph , for a tool to visualize the graph of references. --derivers Return the derivation(s) leading to the given store items (see Derivations ). For example, this command: guix gc --derivers `guix package -I ^emacs$ | cut -f4` returns the .drv file(s) leading to the emacs package installed in your profile. Note that there may be zero matching .drv files, for instance because these files have been garbage-collected. There can also be more than one matching .drv due to fixed-output derivations. Lastly, the following options allow you to check the integrity of the store and to control disk usage. --verify[= options ] Verify the integrity of the store. By default, make sure that all the store items marked as valid in the database of the daemon actually exist in /gnu/store . When provided, options must be a comma-separated list containing one or more of contents and repair . When passing --verify=contents , the daemon computes the content hash of each store item and compares it against its hash in the database. Hash mismatches are reported as data corruptions. Because it traverses all the files in the store , this command can take a long time, especially on systems with a slow disk drive. Using --verify=repair or --verify=contents,repair causes the daemon to try to repair corrupt store items by fetching substitutes for them (see Substitutes ). Because repairing is not atomic, and thus potentially dangerous, it is available only to the system administrator. A lightweight alternative, when you know exactly which items in the store are corrupt, is guix build --repair (see 调用guix build ). --optimize Optimize the store by hard-linking identical files—this is deduplication . The daemon performs deduplication after each successful build or archive import, unless it was started with --disable-deduplication (see --disable-deduplication ). Thus, this option is primarily useful when the daemon was running with --disable-deduplication . Next: 通道 , Previous: 调用guix gc , Up: 软件包管理 [ Contents ][ Index ] 4.6 Invoking guix pull Packages are installed or upgraded to the latest version available in the distribution currently available on your local machine. To update that distribution, along with the Guix tools, you must run guix pull : the command downloads the latest Guix source code and package descriptions, and deploys it. Source code is downloaded from a Git repository, by default the official GNU Guix repository, though this can be customized. On completion, guix package will use packages and package versions from this just-retrieved copy of Guix. Not only that, but all the Guix commands and Scheme modules will also be taken from that latest version. New guix sub-commands added by the update also become available. Any user can update their Guix copy using guix pull , and the effect is limited to the user who run guix pull . For instance, when user root runs guix pull , this has no effect on the version of Guix that user alice sees, and vice versa. The result of running guix pull is a profile available under ~/.config/guix/current containing the latest Guix. Thus, make sure to add it to the beginning of your search path so that you use the latest version, and similarly for the Info manual (see 文档 ): export PATH="$HOME/.config/guix/current/bin:$PATH" export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH" The --list-generations or -l option lists past generations produced by guix pull , along with details about their provenance: $ guix pull -l Generation 1 Jun 10 2018 00:18:18 guix 65956ad repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe Generation 2 Jun 11 2018 11:02:49 guix e0cc7f6 repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d 2 new packages: keepalived, libnfnetlink 6 packages upgraded: emacs-nix-mode@2.0.4, guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac, heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4 Generation 3 Jun 13 2018 23:31:07 (current) guix 844cc1c repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: 844cc1c8f394f03b404c5bb3aee086922373490c 28 new packages: emacs-helm-ls-git, emacs-helm-mu, … 69 packages upgraded: borg@1.1.6, cheese@3.28.0, … See guix describe , for other ways to describe the current status of Guix. This ~/.config/guix/current profile works like any other profile created by guix package (see 调用guix package ). That is, you can list generations, roll back to the previous generation—i.e., the previous Guix—and so on: $ guix package -p ~/.config/guix/current --roll-back switched from generation 3 to 2 $ guix package -p ~/.config/guix/current --delete-generations=1 deleting /var/guix/profiles/per-user/charlie/current-guix-1-link The guix pull command is usually invoked with no arguments, but it supports the following options: --url= url --commit= commit --branch= branch Download code for the guix channel from the specified url , at the given commit (a valid Git commit ID represented as a hexadecimal string), or branch . These options are provided for convenience, but you can also specify your configuration in the ~/.config/guix/channels.scm file or using the --channels option (see below). --channels= file -C file Read the list of channels from file instead of ~/.config/guix/channels.scm . file must contain Scheme code that evaluates to a list of channel objects. See 通道 , for more information. --news -N Display the list of packages added or upgraded since the previous generation. This is the same information as displayed upon guix pull completion, but without ellipses; it is also similar to the output of guix pull -l for the last generation (see below). --list-generations[= pattern ] -l [ pattern ] List all the generations of ~/.config/guix/current or, if pattern is provided, the subset of generations that match pattern . The syntax of pattern is the same as with guix package --list-generations (see 调用guix package ). See 调用guix describe , for a way to display information about the current generation only. --profile= profile -p profile Use profile instead of ~/.config/guix/current . --dry-run -n Show which channel commit(s) would be used and what would be built or substituted but do not actually do it. --system= system -s system Attempt to build for system —e.g., i686-linux —instead of the system type of the build host. --verbose Produce verbose output, writing build logs to the standard error output. --bootstrap Use the bootstrap Guile to build the latest Guix. This option is only useful to Guix developers. The channel mechanism allows you to instruct guix pull which repository and branch to pull from, as well as additional repositories containing package modules that should be deployed. See 通道 , for more information. In addition, guix pull supports all the common build options (see 普通的构建选项 ). Next: Inferiors , Previous: 调用guix pull , Up: 软件包管理 [ Contents ][ Index ] 4.7 通道 Guix and its package collection are updated by running guix pull (see 调用guix pull ). By default guix pull downloads and deploys Guix itself from the official GNU Guix repository. This can be customized by defining channels in the ~/.config/guix/channels.scm file. A channel specifies a URL and branch of a Git repository to be deployed, and guix pull can be instructed to pull from one or more channels. In other words, channels can be used to customize and to extend Guix, as we will see below. 4.7.1 Using a Custom Guix Channel The channel called guix specifies where Guix itself—its command-line tools as well as its package collection—should be downloaded. For instance, suppose you want to update from your own copy of the Guix repository at example.org , and specifically the super-hacks branch, you can write in ~/.config/guix/channels.scm this specification: ;; Tell 'guix pull' to use my own repo. (list (channel (name 'guix) (url "https://example.org/my-guix.git") (branch "super-hacks"))) From there on, guix pull will fetch code from the super-hacks branch of the repository at example.org . 4.7.2 Specifying Additional Channels You can also specify additional channels to pull from. Let's say you have a bunch of custom package variants or personal packages that you think would make little sense to contribute to the Guix project, but would like to have these packages transparently available to you at the command line. You would first write modules containing those package definitions (see 软件包模块 ), maintain them in a Git repository, and then you and anyone else can use it as an additional channel to get packages from. Neat, no? Warning: Before you, dear user, shout—“woow this is soooo coool !”—and publish your personal channel to the world, we would like to share a few words of caution: Before publishing a channel, please consider contributing your package definitions to Guix proper (see 贡献 ). Guix as a project is open to free software of all sorts, and packages in Guix proper are readily available to all Guix users and benefit from the project's quality assurance process. When you maintain package definitions outside Guix, we, Guix developers, consider that the compatibility burden is on you . Remember that package modules and package definitions are just Scheme code that uses various programming interfaces (APIs). We want to remain free to change these APIs to keep improving Guix, possibly in ways that break your channel. We never change APIs gratuitously, but we will not commit to freezing APIs either. Corollary: if you're using an external channel and that channel breaks, please report the issue to the channel authors , not to the Guix project. You've been warned! Having said this, we believe external channels are a practical way to exert your freedom to augment Guix' package collection and to share your improvements, which are basic tenets of free software . Please email us at guix-devel@gnu.org if you'd like to discuss this. To use a channel, write ~/.config/guix/channels.scm to instruct guix pull to pull from it in addition to the default Guix channel(s): ;; Add my personal packages to those Guix provides. (cons (channel (name 'my-personal-packages) (url "https://example.org/personal-packages.git")) %default-channels) Note that the snippet above is (as always!) Scheme code; we use cons to add a channel the list of channels that the variable %default-channels is bound to (see cons and lists in GNU Guile Reference Manual ). With this file in place, guix pull builds not only Guix but also the package modules from your own repository. The result in ~/.config/guix/current is the union of Guix with your own package modules: $ guix pull --list-generations … Generation 19 Aug 27 2018 16:20:48 guix d894ab8 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300 my-personal-packages dd3df5e repository URL: https://example.org/personal-packages.git branch: master commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb 11 new packages: my-gimp, my-emacs-with-cool-features, … 4 packages upgraded: emacs-racket-mode@0.0.2-2.1b78827, … The output of guix pull above shows that Generation 19 includes both Guix and packages from the my-personal-packages channel. Among the new and upgraded packages that are listed, some like my-gimp and my-emacs-with-cool-features might come from my-personal-packages , while others come from the Guix default channel. To create a channel, create a Git repository containing your own package modules and make it available. The repository can contain anything, but a useful channel will contain Guile modules that export packages. Once you start using a channel, Guix will behave as if the root directory of that channel's Git repository has been added to the Guile load path (see Load Paths in GNU Guile Reference Manual ). For example, if your channel contains a file at my-packages/my-tools.scm that defines a Guile module, then the module will be available under the name (my-packages my-tools) , and you will be able to use it like any other module (see 模块 in GNU Guile Reference Manual ). 4.7.3 Declaring Channel Dependencies Channel authors may decide to augment a package collection provided by other channels. They can declare their channel to be dependent on other channels in a meta-data file .guix-channel , which is to be placed in the root of the channel repository. The meta-data file should contain a simple S-expression like this: (channel (version 0) (dependencies (channel (name some-collection) (url "https://example.org/first-collection.git")) (channel (name some-other-collection) (url "https://example.org/second-collection.git") (branch "testing")))) In the above example this channel is declared to depend on two other channels, which will both be fetched automatically. The modules provided by the channel will be compiled in an environment where the modules of all these declared channels are available. For the sake of reliability and maintainability, you should avoid dependencies on channels that you don't control, and you should aim to keep the number of dependencies to a minimum. 4.7.4 Replicating Guix The guix pull --list-generations output above shows precisely which commits were used to build this instance of Guix. We can thus replicate it, say, on another machine, by providing a channel specification in ~/.config/guix/channels.scm that is “pinned” to these commits: ;; Deploy specific commits of my channels of interest. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300")) (channel (name 'my-personal-packages) (url "https://example.org/personal-packages.git") (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb"))) The guix describe --format=channels command can even generate this list of channels directly (see 调用guix describe ). At this point the two machines run the exact same Guix , with access to the exact same packages . The output of guix build gimp on one machine will be exactly the same, bit for bit, as the output of the same command on the other machine. It also means both machines have access to all the source code of Guix and, transitively, to all the source code of every package it defines. This gives you super powers, allowing you to track the provenance of binary artifacts with very fine grain, and to reproduce software environments at will—some sort of “meta reproducibility” capabilities, if you will. See Inferiors , for another way to take advantage of these super powers. Next: 调用guix describe , Previous: 通道 , Up: 软件包管理 [ Contents ][ Index ] 4.8 Inferiors 注: The functionality described here is a “technology preview” as of version 1.0.1. As such, the interface is subject to change. Sometimes you might need to mix packages from the revision of Guix you're currently running with packages available in a different revision of Guix. Guix inferiors allow you to achieve that by composing different Guix revisions in arbitrary ways. Technically, an “inferior” is essentially a separate Guix process connected to your main Guix process through a REPL (see 调用guix repl ). The (guix inferior) module allows you to create inferiors and to communicate with them. It also provides a high-level interface to browse and manipulate the packages that an inferior provides— inferior packages . When combined with channels (see 通道 ), inferiors provide a simple way to interact with a separate revision of Guix. For example, let's assume you want to install in your profile the current guile package, along with the guile-json as it existed in an older revision of Guix—perhaps because the newer guile-json has an incompatible API and you want to run your code against the old API. To do that, you could write a manifest for use by guix package --manifest (see 调用guix package ); in that manifest, you would create an inferior for that old Guix revision you care about, and you would look up the guile-json package in the inferior: (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;for 'first' (define channels ;; This is the old revision from which we want to ;; extract guile-json. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; An inferior representing the above revision. (inferior-for-channels channels)) ;; Now create a manifest with the current "guile" package ;; and the old "guile-json" package. (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile"))) On its first run, guix package --manifest might have to build the channel you specified before it can create the inferior; subsequent runs will be much faster because the Guix revision will be cached. The (guix inferior) module provides the following procedures to open an inferior: Scheme Procedure: inferior-for-channels channels [#:cache-directory] [#:ttl] Return an inferior for channels , a list of channels. Use the cache at cache-directory , where entries can be reclaimed after ttl seconds. This procedure opens a new connection to the build daemon. As a side effect, this procedure may build or substitute binaries for channels , which can take time. Scheme Procedure: open-inferior directory [#:command "bin/guix"] Open the inferior Guix in directory , running directory / command repl or equivalent. Return #f if the inferior could not be launched. The procedures listed below allow you to obtain and manipulate inferior packages. Scheme Procedure: inferior-packages inferior Return the list of packages known to inferior . Scheme Procedure: lookup-inferior-packages inferior name [ version ] Return the sorted list of inferior packages matching name in inferior , with highest version numbers first. If version is true, return only packages with a version number prefixed by version . Scheme Procedure: inferior-package? obj Return true if obj is an inferior package. Scheme Procedure: inferior-package-name package Scheme Procedure: inferior-package-version package Scheme Procedure: inferior-package-synopsis package Scheme Procedure: inferior-package-description package Scheme Procedure: inferior-package-home-page package Scheme Procedure: inferior-package-location package Scheme Procedure: inferior-package-inputs package Scheme Procedure: inferior-package-native-inputs package Scheme Procedure: inferior-package-propagated-inputs package Scheme Procedure: inferior-package-transitive-propagated-inputs package Scheme Procedure: inferior-package-native-search-paths package Scheme Procedure: inferior-package-transitive-native-search-paths package Scheme Procedure: inferior-package-search-paths package These procedures are the counterpart of package record accessors (see 软件包引用 ). Most of them work by querying the inferior package comes from, so the inferior must still be live when you call these procedures. Inferior packages can be used transparently like any other package or file-like object in G-expressions (see G-表达式 ). They are also transparently handled by the packages->manifest procedure, which is commonly use in manifests (see the --manifest option of guix package ). Thus you can insert an inferior package pretty much anywhere you would insert a regular package: in manifests, in the packages field of your operating-system declaration, and so on. Next: 调用guix archive , Previous: Inferiors , Up: 软件包管理 [ Contents ][ Index ] 4.9 Invoking guix describe Often you may want to answer questions like: “Which revision of Guix am I using?” or “Which channels am I using?” This is useful information in many situations: if you want to replicate an environment on a different machine or user account, if you want to report a bug or to determine what change in the channels you are using caused it, or if you want to record your system state for reproducibility purposes. The guix describe command answers these questions. When run from a guix pull ed guix , guix describe displays the channel(s) that it was built from, including their repository URL and commit IDs (see 通道 ): $ guix describe Generation 10 Sep 03 2018 17:32:44 (current) guix e0fa68c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e0fa68c7718fffd33d81af415279d6ddb518f727 If you're familiar with the Git version control system, this is similar in spirit to git describe ; the output is also similar to that of guix pull --list-generations , but limited to the current generation (see the --list-generations option ...
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/zh-cn/guix.zh_CN.html - [detail] - [similar]
PREV NEXT
Powered by Hyper Estraier 1.4.13, with 213361 documents and 1081397 words.