Руководство по GNU Guix

Table of Contents

Next: , Up: (dir)   [Contents][Index]

GNU Guix

В этом документе описывается GNU Guix версии 1.3.0 — менеджер пакетов, написанный для системы 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 Weblate.


Next: , Previous: , Up: Top   [Contents][Index]

1 Введение

GNU Guix1 — это утилита для управления пакетами и дистрибутив системы GNU. Guix позволяет непривилегированным пользователям устанавливать, обновлять и удалять программные пакеты, откатываться до предыдущих наборов пакетов, собирать пакеты из исходников и обеспечивает создание и поддержку программного окружения в целом.

Вы можете установить GNU Guix поверх существующей системы GNU/Linux, и она дополнит функции системы новой утилитой, не внося помехи (see Установка). Или можно использовать отдельную операционную систему — Guix System2. See Дистрибутив GNU.


Next: , Up: Введение   [Contents][Index]

1.1 Управление программным обеспечением Guix Way

Guix provides a command-line package management interface (see Управление пакетами), tools to help with software development (see Разработка), command-line utilities for more advanced usage (see Утилиты), as well as Scheme programming interfaces (see Программный интерфейс). Его демон сборки отвечает за сборку пакетов по запросам пользователей (see Настройка демона) и за скачивание компилированных бинарников из авторизованных ресурсов (see Подстановки).

Guix включает определения пакетов для множества проектов GNU и не-GNU, каждый из которых уважает свободу пользователя в работе за компьютером. Он расширяемый: пользователи могут писать свои собственные определения пакетов (see Описание пакетов) и делать их доступными как независимые пакетные модули (see Пакетные модули). Он также настраиваемый: пользователи могут получать специальные определения пакетов из существующих, в том числе через командную строку (see Параметры преобразования пакета).

Под капотом Guix работает как функциональный пакетный менеджер — принцип, впервые введённый Nix (see Благодарности). В Guix процесс сборки и установки пакета рассматривается как функция в математическом смысле. Эта функция принимает входные данные, как например, скрипты сборки, компилятор, её результат зависит только от входных данных, и он не может зависеть от программ или скриптов, которые не подаются на вход явным образом. Функция сборки всегда производит один результат, когда получает один и тот же набор входных данных. Она не может как-либо изменять окружение запущенной системы; например, она не может создавать, изменять или удалять файлы за пределами её директорий сборки и установки. Это достигается так: процесс сборки запускается в изолированном окружении (или контейнере), в котором видны только входные данные, заданные явно.

Результат работы функций сборки пакетов кешируется в файловой системе в специальной директории, называемой склад (see Хранилище).Каждый пакет устанавливается в собственную директорию склада, по умолчанию — под /gnu/store. Имя директории содержит хеш всех входных данных, используемых для сборки этого пакета, так что изменение входных данных порождает различные имена директорий.

Этот подход является принципиальным, на нём основаны ключевые особенностей Guix: поддержка транзакционного обновления пакета и откаты, установка для отдельного пользователя, сборка мусора от пакетов (see Особенности).


Previous: , Up: Введение   [Contents][Index]

1.2 Дистрибутив GNU

Guix поставляется с дистрибутивом системы GNU, полностью состоящим из свободного программного обеспечения 3. Дистрибутив можно установить отдельно (see Установка системы), но также можно установить Guix в качестве пакетного менеджера поверх установленной системы GNU/Linux (see Установка). Когда нам нужно провести различие между ними, мы называем самодостаточный дистрибутив Guix System.

Дистрибутив предоставляет основные пакеты GNU, такие как GNU libc, GCC и Binutils, а также многие приложения GNU и не-GNU. Полный список доступных пакетов можно просмотреть по онлайн или запустив guix package (see Вызов guix package):

guix package --list-available

Наша цель — предоставить состоящий на 100% из свободного программного обеспечения рабочий дистрибуив Linux или другие варианты GNU. Мы ориентируемся на продвижении и полноценной интеграции компонентов GNU и поддержке программ и утилит, которые помогают пользователям реализовать их свободы.

Пакеты в данные момент доступны для следующих платформ:

x86_64-linux

архитектура Intel/AMD x86_64 с ядром Linux-Libre.

i686-linux

архитектура Intel 32-bit (IA32) с ядром Linux-Libre.

armhf-linux

Архитектура ARMv7-A с hard float, Thumb-2 и NEON, используя двочиный интерфейс приложений EABI hard-float (ABI), с ядром Linux-Libre.

aarch64-linux

процессоры little-endian 64-bit ARMv8-A с ядром Linux-Libre.

i586-gnu

GNU/Hurd на 32 битной архитектуре Intel (IA32).

Эта конфигурация является экспериментальной и находится в разработке. Самый простой способ попробовать - настроить экземпляр hurd-vm-service-type на вашем GNU/Linux компьютере (see hurd-vm-service-type). See Содействие, о том, как помочь!

mips64el-linux (deprecated)

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, there is no ongoing work to ensure that this architecture still works. Should someone decide they wish to revive this architecture then the code is still available.

powerpc64le-linux

64-битные процессоры Power ISA с прямым порядком байтов, ядро Linux-Libre. Сюда входят системы POWER9, такие какRYF Talos II mainboard. Эта платформа доступна как «предварительная версия»: хотя она и поддерживается, заменители еще не доступны (see Подстановки), а некоторые пакеты могут не собираться (see Отслеживание ошибок и патчей) . Тем не менее, сообщество Guix активно работает над улучшением этой поддержки, и сейчас отличное время, чтобы попробовать и принять участие!

Пользуясь системой Guix, вы объявляете все аспекты конфигурации системы, и Guix выполняет установку инстранции ОС транзакционным, повторяемым способом, не имеющей состояния (stateless) (see Конфигурирование системы). Система Guix использует ядро Linux-libre, систему инициализации Shepherd (see Введение in The GNU Shepherd Manual), хорошо известные утилиты и тулчейны GNU, а также графическое окружение на выбор.

Guix System is available on all the above platforms except mips64el-linux and powerpc64le-linux.

Информация о портировании на другие архитектуры и ядра доступна в see Портирование.

Дистрибутив созаётся совместными усилиями, приглашаем вас! См. See Содействие, чтобы узнать о том, как вы можете помочь.


Next: , Previous: , Up: Top   [Contents][Index]

2 Установка

Примечание: Мы рекомендуем использовать этот скрипт установки для установки Guix на существующую систему GNU/Linux, называемый далее чужой дистрибутив.4 Скрипт автоматизирует скачивание, установку и начальную конфигурацию Guix. Он должен запускаться от пользователя root.

При установке на чужой дистрибутив GNU Guix дополняет доступные утилиты без внесения помех. Его данные живут только в двух директориях — обычно /gnu/store и /var/guix; другие файлы вашей системы, как /etc, остаются нетронутыми.

Установленный Guix можно обновлять командой guix pull (see Запуск guix pull).

Если вы предпочитаете выполнять шаги установки вручную или хотита подправить их, следующие параграфы будут полезны. В них описаны требования Guix к программному обеспечению, а также процесс ручной установки до запуска в работу.


Next: , Up: Установка   [Contents][Index]

2.1 Бинарная установка

Этот раздел описывает, как установить Guix на обычную систему из отдельного архива, который содержит бинарники Guix и все его зависимости. Это обычно быстрее установки из исходных кодов, которая описана в следующем разделе. Единственное требование - иметь GNU tar и Xz.

Примечание: Мы рекомендуем использовать этот установочный скрипт. Скрипт автоматизирует скачивание, установку и начальные шаги конфигурации, описанные ниже. Он должен запускаться от пользователя root. Как root вы можете запустить это:

cd /tmp
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh

Когда закончите, вам может понадобиться see Установка приложения для дополнительной настройки и Начиная!

Установка производится следующими образом:

  1. Download the binary tarball from ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz’, where x86_64-linux can be replaced with i686-linux for an i686 (32-bits) machine already running the kernel Linux, and so on (see Дистрибутив GNU).

    Убедитесь в аутентичности архива, скачав файл .sig и запустив:

    $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz.sig
    $ gpg --verify guix-binary-1.3.0.x86_64-linux.tar.xz.sig
    

    Если это завершается ошибкой, значит у вас нет необходимого публичного ключа, тогда запустите команду для импорта ключа:

    $ wget 'https://sv.gnu.org/people/viewgpg.php?user_id=127547' \
          -qO - | gpg --import -
    

    и запустите команду gpg --verify.

    Обратите внимание, что предупреждение по типу «Этот ключ не сертифицирован с доверенной подписью!» является нормальным.

  2. Теперь вам необходимы привилегии пользователя root. В зависимости от вашего дистрибутива, можно запустить su - или sudo -i. Под root запустите:
    # cd /tmp
    # tar --warning=no-timestamp -xf \
         /path/to/guix-binary-1.3.0.x86_64-linux.tar.xz
    # mv var/guix /var/ && mv gnu /
    

    Это создаёт /gnu/store (see Хранилище) и /var/guix. Последнее содержит готовый к использованию профиль для root (подробнее в следующем шаге).

    Не распаковывайте архив в работающую систему Guix, так как это перезапишет её основные файлы.

    The --warning=no-timestamp option makes sure GNU tar does not emit warnings about “implausibly old time stamps” (such warnings were triggered by GNU tar 1.26 and older; recent versions are fine). They stem from the fact that all the files in the archive have their modification time set to 1 (which means January 1st, 1970). This is done on purpose to make sure the archive content is independent of its creation time, thus making it reproducible.

  3. Сделайте профиль доступным по пути ~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
    
  4. Создайте группу и пользовательские учётные записи, как это обозначено в (see Установка окружения сборки).
  5. Запустите демон и сделайте добавьте его в автоззагрузку после старта.

    Если ваш дистрибутив использует систему инициализации systemd, этого можно добиться следующими командами:

    # cp ~root/.config/guix/current/lib/systemd/system/gnu-store.mount \
         ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
        /etc/systemd/system/
    # systemctl enable --now gnu-store.mount guix-daemon
    

    Если ваш дистрибутив использует систему инициализации Upstart:

    # 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
    
  6. Сделайте команду 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).

  7. Чтобы использовать подстановки из ci.guix.gnu.org или из одного из зеркал (see Подстановки), авторизуйте их:
    # guix archive --authorize < \
         ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
    
  8. Каждый пользователь, возможно, должен выполнить дополнительные шаги, чтобы сделать их окружение Guix готовым к использованию see Установка приложения.

Вуаля! Установка завершена!

Вы можете проверить, что Guix работает, установив тестовый пакет для профиля root:

# guix install hello

Архив для бинарной установки может быть воспроизведён (повторён) и проверен простым запуском следующей команды в дереве исходников Guix:

make guix-binary.system.tar.xz

..., что в свою очередь, выполнит:

guix pack -s system --localstatedir \
  --profile-name=current-guix guix

See Запуск guix pack для подробной информации об этом полезном инструменте.


Next: , Previous: , Up: Установка   [Contents][Index]

2.2 Требования

Этот раздел содержит требования для сборки Guix из исходников. Пожалуйста, смотрите файлы README и INSTALL в дереве исходников Guix для подробной информации.

GNU Guix доступен для скачивания на сайте https://www.gnu.org/software/guix/.

GNU Guix зависит от следующих пакетов:

Следующие зависимости необязательны:

Unless --disable-daemon was passed to configure, the following packages are also needed:

When configuring Guix on a system that already has a Guix installation, be sure to specify the same state directory as the existing installation using the --localstatedir option of the configure script (see localstatedir in GNU Coding Standards). Usually, this localstatedir option is set to the value /var. The configure script protects against unintended misconfiguration of localstatedir so you do not inadvertently corrupt your store (see Хранилище).


Next: , Previous: , Up: Установка   [Contents][Index]

2.3 Запуск набора тестов

После успешного завершения configure и make хорошо бы выполнить набор тестов. Это поможет выявить проблемы установки или в окружении, как и баги самого Guix (на самом деле, отчёты об ошибках тестов помогают улучшить ПО). Чтобы запустить тесты, напечатайте:

make check

Тесты можно выполнять параллельно при включении опции -j в GNU make, так быстрее. Первый запуск может длиться несколько минут на топовой машине, последующие запуски будут быстрее, так как склад, который создаётся для тестов, уже закеширует различные вещи.

Также можно запустить отдельные наборы тестов, используя переменную TESTS, как в примере:

make check TESTS="tests/store.scm tests/cpio.scm"

По умолчанию результаты тестов выводятся в файл. Чтобы просмотреть результаты каждого отдельного теста, нужно задать переменную makifile SCM_LOG_DRIVER_FLAGS, как в примере:

make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"

Лежащий в основе кастомный SRFI 64 Automake тестовый драйвер, используемый для ’проверки’ набора тестов (расположенный в build-aux/test-driver.scm) также позволяет выбрать, какие тестовые случаи запускать на более высоком уровне, при помощи опций --select и --exclude. Вот пример для запуска всех тестовых случаев из файла tests/packages.scm, чьи имена начинаются с “transaction-upgrade-entry”:

export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry"
make check TESTS="tests/packages.scm"

Желающие проверить результаты неудачных тестов прямо из командной строки могут добавить --errors-only=yes к makefile переменнойSCM_LOG_DRIVER_FLAGS и задать Automake makefile переменную VERBOSE, как в:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1

Опция --show-duration=yes может быть использована чтобы отобразить продолжительность отдельных тестовых случаев, когда использована вместе с --brief=no:

make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"

See Parallel Test Harness in GNU Automake для получения дополнительной информации о Automake Parallel Test Harness.

В случае ошибки, пожалуйста, отправьте сообщение на bug-guix@gnu.org и присоедините файл test-suite.log. Пожалуйста, обозначьте в сообщении используемую версию Guix, а также номера версий зависимостей (see Требования).

Guix также идёт с набором тестов для всей системы, который проверяет нстранцию системы Guix. Их можно запустить только в системах, где Guix уже установлен, так:

make check-system

или, опять же, задав TESTS, чтобы выбрать список тестов для запуска:

make check-system TESTS="basic mcron"

Тесты системы определены в модулях (gnu tests …). При работе они запускают операционную систему под легковесным инструментарием в виртуальной машине. Они могут выполнять тяжёлые вычисления или довольно простые в зависимости от наличия подстановок их зависимостей (see Подстановки). Некоторые из них требуют много места для работы с образами виртуальной машины.

Конечно, в случае неудачных тестов, пожалуйста, направьте детали на bug-guix@gnu.org.


Next: , Previous: , Up: Установка   [Contents][Index]

2.4 Настройка демона

Такие операции, как сборка пакета или запуск сборщика мусора, выполняются запуском специальных процесса — демона сборки — по запросам клиентов. Только демон имеет доступ к складу и его базе данных. Так что операции управления складом выполняются с помощью демона. Например, инструменты командной строки, как guix package и guix build, обычно взаимодействуют с демоном через удалённый вызов процедур (RPC) и сообщают, что необходимо сделать.

Следующие разделы поясняют как настроить окружение демона сборки. Смотрите также Подстановки для подробной инсорации о том, как разрешить демону скачивать собранные бинарники.


Next: , Up: Настройка демона   [Contents][Index]

2.4.1 Установка окружения сборки

В случае стандартной многопользовательской установки Guix и его демон (программа guix-daemon) установливаются системным администратором; /gnu/store принадлежит root, и guix-daemon запущен от root. Непривилегированные пользователи могут пользоваться инструментами Guix, чтобы собирать пакеты или получить доступ к складу с какой-либо целью, и демон выполнит это по их запросу, убедившись, что склад находится в должном состоянии, и разрешив сборку пакетов и разделение их между пользователями.

Когда guix-daemon запущен от root, возможно, из соображений безопасности вы не примете того, что процессы сборки пакетов тоже выполняются от root. Чтобы избежать этого, необходимо создать специальных пользователей для сборки. Ими будет пользоваться процесс сборки, запускаемый демоном. Эти пользователи сборки не должны иметь оболочки и домашней директории — они просто будут использоваться, когда демон сбрасывает привилегии 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,kvm вместо -G guixbuild (see Вызов guix system).

Программа guix-daemon тогда может запускаться от root следующим образом5:

# guix-daemon --build-users-group=guixbuild

Так демон стартует процессы сборки в chroot под одним из пользователей группы guixbuilder. В GNU/Linux по умолчанию окружение chroot содержит только следующее:

You can influence the directory where the daemon stores build trees via the TMPDIR environment variable. However, the build tree within the chroot is always called /tmp/guix-build-name.drv-0, where name is the derivation name—e.g., coreutils-8.24. This way, the value of TMPDIR does not leak inside build environments, which avoids discrepancies in cases where build processes capture the name of their build tree.

The daemon also honors the http_proxy and https_proxy environment variables for HTTP and HTTPS downloads it performs, be it for fixed-output derivations (see Деривации) or for substitutes (see Подстановки).

If you are installing Guix as an unprivileged user, it is still possible to run guix-daemon provided you pass --disable-chroot. However, build processes will not be isolated from one another, and not from the rest of the system. Thus, build processes may interfere with each other, and may access programs, libraries, and other files available on the system—making it much harder to view them as pure functions.


Next: , Previous: , Up: Настройка демона   [Contents][Index]

2.4.2 Использование функционала разгрузки

При желании демон сборки может offload производные сборки на других машинах, на которых запущен Guix, используя offload build hook7. Когда данная функция включена, список указанных пользователем машин для сборки считывается из /etc/guix/machines.scm; каждый раз, когда запрашивается сборка, например через guix build, демон пытается выгрузить ее на одну из машин, удовлетворяющих ограничениям производной сборки, в частности, ее системным типам—например, x86_64-linux. На одной машине можеь быть несколько типов систем, либо потому, что архитектура изначально поддерживает ее, либо через эмуляцию (see Transparent Emulation with QEMU). Отсутствующие необходимые условия для сборки копируются по SSH на целевой компьютер, который затем продолжает сборку; в случает успеха выходные данные копируются на исходную машину. Средство разгрузки поставляется с базовым планировщиком, который пытается выбрать лучшую машину. Лучшая машина выбирается среди доступных машин на основании такиз критериев как:

  1. Наличие слота для сборки. Машина для сборки может иметь столько слотов для сборки (соединений), сколько указано в значении parallel-builds определения объекта build-machine.
  2. Ее относительная скорость, указанная через значение speed определения объекта build-machine.
  3. Ее нагрузка. Нормализованная нагрузка на машину должна быть ниже порогового значения, которое можно настроить с помощью поля overload-threshold объекта build-machine.
  4. Доступность дискового пространства. Должно быть доступно более 100 МБ.

Файл /etc/guix/machines.scm обычно выглядит так:

(list (build-machine
           (name "eightysix.example.org")
           (systems (list "x86_64-linux" "i686-linux"))
           (host-key "ssh-ed25519 AAAAC3Nza…")
           (user "bob")
           (speed 2.))     ;incredibly fast!

      (build-machine
        (name "armeight.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")
        (private-key
         (string-append (getenv "HOME")
                        "/.ssh/identity-for-guix"))))

In the example above we specify a list of two build machines, one for the x86_64 and i686 architectures and one for the aarch64 architecture.

По факту, этот файл, что не удивительно, является файлом Scheme, и он имеет значение, когда запускается хук разгрузки. Он возвращает объекты класса build-machine. Приведённый пример показывает фиксированный список машин для сборки, но можно представить, скажем, используя DNS-SD, он может возвращать список потенциальных машин, обнаруженных в локальной сети (see Guile-Avahi in Using Avahi in Guile Scheme Programs). Тип данных build-machine описан ниже.

Тип данных: build-machine

Этот тип данных представляет машины для сборки, на которые демон может разгружать сборки. Важные поля:

name

Имя хоста удалённой машины.

systems

The system types the remote machine supports—e.g., (list "x86_64-linux" "i686-linux").

user

Аккаунт пользователя, используемый для соединения с удалённой машиной через SSH. Отметим, что ключ-пара SSH не должна быть защищена парольной фразой, чтобы разрешить не интерактивные авторизации.

host-key

Это публичный ключ хоста в формает OpenSSH. Он используется при аутентификации машины, когда мы подсоединяемс к ней. Это длинная строка, которая выглядит примерно так:

ssh-ed25519 AAAAC3NzaC…mde+UhL hint@example.org

Если на машине запущен демон OpenSSH sshd, ключ хоста может быть найден в файле под директорией /etc/ssh, например, /etc/ssh/ssh_host_ed25519_key.pub.

Если на машине запущен демон SSH GNU lsh, lshd, тогда ключ хоста расположен в /etc/lsh/host-key.pub или подобном файле. Его можно конвертировать в формат OpenSSH, используя lsh-export-key (see Converting keys in LSH Manual):

$ lsh-export-key --openssh < /etc/lsh/host-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV…

Список необязательных полей:

port (default: 22)

Номер порта сервера SSH на машине.

private-key (default: ~root/.ssh/id_rsa)

Файл приватного ключа в формате OpenSSH, используемого в соединении с машиной. Этот ключ не должен быть защищён парольной фразой.

Отметим, что значение по умолчанию — приватный ключ аккаунта root. Убедитесь, что он существует, если вы используете настройки по умолчанию.

compression (default: "zlib@openssh.com,zlib")
compression-level (default: 3)

Методы компрессии уровня SSH и уровень компрессии.

Отметим, что разгрузка зависит от компрессии SSH, что уменьшает использование траффика при передаче файлов на и с машин для сборки.

daemon-socket (default: "/var/guix/daemon-socket/socket")

Имя файла сокета Unix-домена, который слушает guix-daemon на удалённой машине.

overload-threshold (default: 0.6)

Порог нагрузки, выше которого потенциальная offload машина не учитывается offload планировщиком. Это значение примерно соответствует общему использованию процессора машиной сборки в диапазоне от 0,0 (0%) до 1,0 (100%). Это также можно отключить, установив overload-threshold в #f.

parallel-builds (default: 1)

Число сборок, которые могут быть запущены на машине.

speed (default: 1.0)

Показатель скорости. Планировщик разгрузки предпримет попытку выбрать машину с наибольшим показателем скорости.

features (default: '())

Набор строк, описывающий специфические функции, которые поддерживаются на машине. Например, "kvm" для машин, которые имеют модули Linux KVM и соответствующую поддерку аппаратного обеспечения. Деривации могут запрашивать функции по имени, и тогда они будут запранированы на соответствующих машинах для сборки.

Команда 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

This will attempt to connect to each of the build machines specified in /etc/guix/machines.scm, make sure Guix is available on each machine, attempt to export to the machine and import from it, and report any error in the process.

Если нужно тестировать другой файл с описанием машин, просто приведите его в командной строке:

# 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 включает файл политик SELinnux 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

Наблюдайте файлы логов SELinux во время работы команды guix build hello, чтобы удостовериться, что SELinux позволяет выполнение необходимых операций.

2.4.3.2 Ограничения

Эта политика не совершенна. Тут есть ряд ограничений или причуд, который нужно учитывать при разворачивании политики SELinux для демона Guix.

  1. guix_daemon_socket_t isn’t actually used. None of the socket operations involve contexts that have anything to do with guix_daemon_socket_t. It doesn’t hurt to have this unused label, but it would be preferable to define socket rules for only this label.
  2. guix gc не может получить доступ к обычным ссылкам профилей. По задумке метка файла назначения символической ссылки не зависит от метки файла самой ссылки. Хотя все профили под $localstatedir помечены, ссылки на эти профили не наследуют метку директории, в которой они находятся. Для ссылок на домашние директории пользователей это будет user_home_t. Но для ссылок из домашней директории root, а также /tmp или рабочей директории HTTP-сервера и т.п., это не работает. guix gc не будет допускаться к чтению и следованию по этим ссылкам.
  3. Функция демона прослушивать соединения TCP может более не работать. Это может потребовать дополнительных правил, потому что SELinux относится к сетевым сокетам иначе, чем к файлам.
  4. В настоящее время всем файлам с именами, соответствующими регулярному выражению /gnu/store/.+-(guix-.+|profile)/bin/guix-daemon, присвоена метка guix_daemon_exec_t; это означает, что любому файлу с таким именем в любом профиле разрешён запуск в домене guix_daemon_t. Это не идеально. Атакующий может собрать пакет, который содержит исполняемый файл и убеить пользователя установить и запустить его, и таким образом он получит доступ к домену guix_daemon_t. В этой связи SELinux мог бы не давать ему доступ к файлам, которые разрешены для процессов в этом домене.

    Вам нужно будет изменить метку (label) каталога хранилища после всех обновлений до guix-daemon, например, после запуска guix pull. Предполагая, что хранилище в /gnu, вы можете это сделать с restorecon -vR /gnu, или другими способами, предусмотренными вашей операционной системой.

    Мы можем создать политику с большими ограничениями во время установки, так чтобы только точное имя исполняемого файла установленного в данный момент guix-daemon было помечено меткой guix_daemon_exec_t вместо того, чтобы использовать регулярное выражение, выбирающее большой ряд файлов. Проблемой в данном случае будет то, что root потребуется устанавливать или обновлять политику во время любой установки в случае, если обновлён исполняемый файл guix-daemon.


Next: , Previous: , Up: Установка   [Contents][Index]

2.5 Вызов guix-daemon

Программа guix-daemon реализует весь функционал доступа к складу. Это включает запуск процессов сборки, запуск сборщика мусора, проверка доступности результата сборки и т.д. Он должен быть запущен от root так:

# guix-daemon --build-users-group=guixbuild

Для подробностей о том, как настроить его, смотрите see Настройка демона.

By default, guix-daemon launches build processes under different UIDs, taken from the build group specified with --build-users-group. In addition, each build process is run in a chroot environment that only contains the subset of the store that the build process depends on, as specified by its derivation (see derivation), plus a set of specific system directories. By default, the latter contains /dev and /dev/pts. Furthermore, on GNU/Linux, the build environment is a container: in addition to having its own file system tree, it has a separate mount name space, its own PID name space, network name space, etc. This helps achieve reproducible builds (see Особенности).

When the daemon performs a build on behalf of the user, it creates a build directory under /tmp or under the directory specified by its TMPDIR environment variable. This directory is shared with the container for the duration of the build, though within the container, the build tree is always called /tmp/guix-build-name.drv-0.

The build directory is automatically deleted upon completion, unless the build failed and the client specified --keep-failed (see --keep-failed).

The daemon listens for connections and spawns one sub-process for each session started by a client (one of the guix sub-commands). The guix processes command allows you to get an overview of the activity on your system by viewing each of the active sessions and clients. See Запуск guix processes, for more information.

Поддерживаются следующие опции командной строки:

--build-users-group=group

Использовать пользователей из группы group для запуска процессов сборки (see build users).

--no-substitutes

Не использовать подстановки для сборок. Это означает — собирать элементы локально вместо того, чтобы скачивать собранные бинарники (see Подстановки).

When the daemon runs with --no-substitutes, clients can still explicitly enable substitution via the set-build-options remote procedure call (see Хранилище).

--substitute-urls=urls

Использовать адреса urls, разделённые пробелом по умолчанию, как список источников подстановок. Когда эта опция пропущена, используется ‘https://ci.guix.gnu.org’.

Это означает, что подстановки могут скачиваться из адресов urls, если конечно они подписаны доверенной подписью (see Подстановки).

See Получение заменителей с других серверов, для получения дополнительной информации о том, как настроить демон для получения заменителей с других серверов.

--no-offload

Do not use offload builds to other machines (see Установка демона разгрузки). That is, always build things locally instead of offloading builds to remote machines.

--cache-failures

Кешировать ошибки сборки. По умолчанию кешируются только успешные сборки.

При установке этой опции можно использовать guix gc --list-failures, чтобы просматривать элементы склада, помеченные как ошибочные; guix gc --clear-failures удаляет элементы склада из кеша ошибок. See Вызов guix gc.

--cores=n
-c n

Использовать n ядер процессора для сборки каждой деривации; 0 означает использовать все доступные.

The default value is 0, but it may be overridden by clients, such as the --cores option of guix build (see Запуск guix build).

The effect is to define the NIX_BUILD_CORES environment variable in the build process, which can then use it to exploit internal parallelism—for instance, by running make -j$NIX_BUILD_CORES.

--max-jobs=n
-M n

Разрешить максимум n параллельных задач сборки. Значение по умолчанию - 1. Установка в 0 означает, чтоб сборки не будут выполняться локально, вместо этого, демон будет разгружать сборки (see Установка демона разгрузки) или просто отчитается об ошибке.

--max-silent-time=seconds

Когда процесс сборки или подстановки молчит более seconds секунд, завершить его и отчитаться об ошибке сборки.

Значение по умолчанию - 0, что значит отключить таймаут.

The value specified here can be overridden by clients (see --max-silent-time).

--timeout=seconds

Точно так же, когда процесс сборки или подстановки длится более seconds, завершить его и отчитаться об ошибке сборки.

Значение по умолчанию - 0, что значит отключить таймаут.

The value specified here can be overridden by clients (see --timeout).

--rounds=N

Собирать каждую деривацию n раз подряд и вызывать ошибку, если результаты последовательных сборок не идентичны бит-к-биту. Отметим, что эта настройка может быть переопределена клиентами в команде, например, guix build (see Запуск guix build).

При использовании вместе с --keep-failed различные результаты сохраняются на складе под /gnu/store/…-check. Это делает возможным просмотр различий между двумя результатами.

--debug

Выводить отладочную информацию.

Это полезно для отладки проблем запуска демона, но затем это может быть переопределено клиентами, например, опцией --verbosity команды guix build (see Запуск guix build).

--chroot-directory=dir

Добавить директорию dir в chroot сборки.

Это может изменить результаты процессов сборки, например, если они используют необязательные (опциональные) зависимости, найденные в dir, если они доступны, но только так, а не иначе. Поэтому не рекомендуется делать так. Вместо этого, убедитесь, что каждая деривация объявляет все необходимые входные данные.

--disable-chroot

Отключить chroot для сборки.

Использование этой опции не рекомендуется, так как опять же это позволит процессам сборки получить доступ к не объявленным зависимостям. Это важно, даже если guix-daemon запущен под аккаунтом непривилегированного пользователя.

--log-compression=type

Архивировать логи сборки методом type. Это один из: gzip, bzip2 или none.

Unless --lose-logs is used, all the build logs are kept in the localstatedir. To save space, the daemon automatically compresses them with Bzip2 by default.

--discover[=yes|no]

Следует ли обнаруживать сервера с заменителями в локальной сети с помощью mDNS and DNS-SD.

Эта функция все еще экспериментальная. Однако есть несколько соображений.

  1. Это может быть быстрее/дешевле, чем загрузка (fetching) с удаленных серверов;
  2. Никаких угроз безопасности, будут использоваться только подлинные заменители (see Аутентификация подстановок);
  3. Объявление злоумышленника guix publish в вашей локальной сети не могут предоставить вам вредоносные двоичные файлы, но они могут узнать, какое программное обеспечение вы устанавливаете;
  4. Серверы могут предоставить заменители через HTTP в незашифрованном виде, поэтому любой в локальной сети может видеть, какое программное обеспечение вы устанавливаете.

Также можно включить или отключить обнаружение сервера с заменителями во время выполнения, запустив:

herd discover guix-daemon on
herd discover guix-daemon off
--disable-deduplication

Отключить автоматическую "дедупликацию" файлов на складе.

По умолчанию файлы, добавленные на склад, автоматически "дедуплицируются": если вновь добавленный файл идентичен другому, найденному на складе, демон делает новый файл жесткой ссылкой на другой файл. Это существенно сокращает использование места на диске за счёт небольшого увеличения запросов ввода/вывода в конце процесса сборки. Эта опция отключает такую оптимизацию.

--gc-keep-outputs[=yes|no]

Сообщить, должен ли сборщик мусора (GC) сохранять выходные данные живой деривации.

When set to yes, the GC will keep the outputs of any live derivation available in the store—the .drv files. The default is no, meaning that derivation outputs are kept only if they are reachable from a GC root. See Вызов guix gc, for more on GC roots.

--gc-keep-derivations[=yes|no]

Сообщить, должен ли сборщик мусора (GC) сохранять деривации, соответствующие живым результатам.

When set to yes, as is the case by default, the GC keeps derivations—i.e., .drv files—as long as at least one of their outputs is live. This allows users to keep track of the origins of items in their store. Setting it to no saves a bit of disk space.

In this way, setting --gc-keep-derivations to yes causes liveness to flow from outputs to derivations, and setting --gc-keep-outputs to yes causes liveness to flow from derivations to outputs. When both are set to yes, the effect is to keep all the build prerequisites (the sources, compiler, libraries, and other build-time tools) of live objects in the store, regardless of whether these prerequisites are reachable from a GC root. This is convenient for developers since it saves rebuilds or downloads.

--impersonate-linux-2.6

On Linux-based systems, impersonate Linux 2.6. This means that the kernel’s uname system call will report 2.6 as the release number.

Это полезно для сборки программ, которые (обычно по ошибке) зависят от версии ядра.

--lose-logs

Do not keep build logs. By default they are kept under localstatedir/guix/log.

--system=system

Считать system текущим типом системы. По умолчанию это пара архитектура/ядро, обнаруженная во время конфигурации, например, x86_64-linux.

--listen=endpoint

Слушать соединения с endpoint. endpoint интерпретируется как имя файла сокета Unix-домена, если начинается с / (знак слеша). В противном случае endpoint интерпретируется как имя хоста или им хоста и порт для прослушивания. Вот несколько примеров:

--listen=/gnu/var/daemon

Слушать соединения с сокетом Unix-домена /gnu/var/daemon, который создаётся при необходимости.

--listen=localhost

Слушать соединения TCP сетевого интерфейса, относящиеся к localhost, на порту 44146.

--listen=128.0.0.42:1234

Слушать соединения TCP сетевого интерфейса, относящиеся к 128.0.0.42, на порту 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.


Next: , Previous: , Up: Установка   [Contents][Index]

2.6 Установка приложения

При использовании дистрибутива GNU/Linux, отличного от системы, называемого также чужой дистрибутив, необходимо несколько дополнительных шагов, чтобы всё работало. Вот некоторые из них.

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 917 MiB. Alternatively, the glibc-utf8-locales is smaller but limited to a few UTF-8 locales.

Переменная GUIX_LOCPATH играет ту же роль, что и LOCPATH (see LOCPATH in The GNU C Library Reference Manual). Но есть два существенных различия:

  1. 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.
  2. 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.

Это важно, потому что использование данных локали другой версией libc может быть неприемлемо.

2.6.2 Служба выбора имён

При использовании Guix на чужом дистрибутиве мы настойчиво рекомендуем, чтобы система запускала демон кеша имён сервисов библиотеки GNU C, nscd, который должен слушать сокет /var/run/nscd/socket. Если это не сделано, приложения, установленные Guix, могут некорректно адресовать имена хостов или аккаунты пользователей и даже падать. Ниже объясняется почему.

Библиотека GNU C реализует выбор имён сервисов (NSS), который представляет собой расширяемый механизм для резолвинга имён в целом: резолвинг имён хостов, аккаунтов пользователей и другое (see Служба выбора имён in The GNU C Library Reference Manual).

Будучи расширяемым, NSS поддерживает плагины, которые предоставляют реализации разрешения новых имён: плагин nss-mdns резолвит имена хостов .local, плагин nis адресует пользовательские аккаунты, используя сервис сетевой информации (NIS) и т.д. Эти дополнительные сервисы адресации настраиваются для всей системы в /etc/nsswitch.conf, и все запущенные в системе программы учитывают эти настройки (see NSS Configuration File in The GNU C Reference Manual).

Когда выполняется разрешение имён, например, вызовом функции C getaddrinfo, приложения вначале делают попытку соединиться с nscd; в случае успеха nscd выполняет разрешение имён по их запросу. Если nscd не запущен, тогда они выполняют разрешение имён самостоятельно, загружая сервисы разрешения имён в их собственные адресные пространства и запуская их. Эти сервисы разрешения имён — файлы libnss_*.so — запускаются dlopen, но они могут поставляться системной библиотекой C, а не библиотекой C, с которой залинковано приложение (библиотека C из Guix).

Вот где кроется проблема — если ваше приложение залинковано с библиотекой C Guix (скажем, glibc 2.24) и пытается загрузить плагины NSS из другой библиотеки C (скажем, libnss_mdns.so для glibc 2.22), это вероятно вызовет падение или резолвинг имени завершится с ошибкой.

Запуск nscd в системе, помимо преимуществ, также исключает эту проблему несовместимости программ, потому что файлы libnss_*.so загружены в процессе nscd, а не в самом приложении.

2.6.3 Шрифты X11

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.

После того, как вы установили или удалили шрифты, или когда вы заметили приложение, которое не находит шрифты, вам может потребоваться установить Fontconfig и принудительно обновить кэш шрифтов, выполнив:

guix install fontconfig
fc-cache -rv

Для отображения в графических приложениях текста на китайском, японском, корейском нужно установить font-adobe-source-han-sans или font-wqy-zenhei. Первый имеет множественный выход, один для языковой семьи (see Пакеты со множественным выходом). Например, следующая команда устанавливает шрифты для китайских языков:

guix install font-adobe-source-han-sans:cn

Старые программы, например, xterm, не используют Fontconfig, а вместо этого вызывают рендеринг шрифтов на стороне сервера. Таким программам необходимо указывать полное имя шрифта, используя XLFD (X Logical Font Description), примерно так:

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

Чтобы иметь возможность использовать такие полные имена для шрифтов TrueType, установленных в вашем профиле Guix, вам нужно расширить пути шрифтов X-сервера:

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

После этого можно запустить xlsfonts (из пакета xlsfonts), чтобы убедиться, что ваши шрифты TrueType находятся там.

2.6.4 Сертификаты X.509

Пакет nss-certs предоставялет сертификаты X.509, которые позволяют программам аутентифицировать веб-серверы и работать через HTTPS.

При использовании Guix на чужом дистрибутиве можно установить этот пакет и определить соответствующие переменные окружения, чтобы пакеты знали, где искать сертификаты. Смотрите See Сертификаты X.509 для подробной информации.

2.6.5 Пакеты Emacs

When you install Emacs packages with Guix, the Elisp files are placed under the share/emacs/site-lisp/ directory of the profile in which they are installed. The Elisp libraries are made available to Emacs through the EMACSLOADPATH environment variable, which is set when installing Emacs itself.

Additionally, autoload definitions are automatically evaluated at the initialization of Emacs, by the Guix-specific guix-emacs-autoload-packages procedure. If, for some reason, you want to avoid auto-loading the Emacs packages installed with Guix, you can do so by running Emacs with the --no-site-file option (see Init File in The GNU Emacs Manual).


Previous: , Up: Установка   [Contents][Index]

2.7 Обновление Guix

Чтобы обновить Guix, запустите:

guix pull

See Запуск guix pull для дополнительной информации.

В ином дистрибутиве вы можете обновить демон сборки, запустив:

sudo -i guix pull

затем (при условии, что ваш дистрибутив использует инструмент управления сервисами systemd):

systemctl restart guix-daemon.service

В системе Guix обновление демона достигается путем перенастройки системы (see guix system reconfigure).


Next: , Previous: , Up: Top   [Contents][Index]

3 Установка системы

Этот раздел объясняет, как установить систему Guix на компьютер. Guix, как пакетный менеджер, можно также установить на уже установленную систему GNU/Linux (see Установка).


Next: , Up: Установка системы   [Contents][Index]

3.1 Ограничения

Мы полагаем, система Guix будет широко применяться для офисных и серверных решений. Гарантия надёжности основана на транзакционных обновлениях, откатах и воспроизводимости. Это наше прочное основание.

Тем не менее, перед началом установки, ознакомьтесь с важной информацией об ограничениях версии 1.3.0:

Мы настойчиво призываем вас присылать отчёты о проблемах (или историиуспеха!). Присоединяйтесь к нам, если вы хотите улучшить Guix. Смотрите See Содействие, чтобы узнать больше.


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.2 По поводу железа

GNU Guix особенно заботится об уважении свободы пользователя при работе за компьютером. Она построена на ядре Linux-libre, что означает, что поддерживается только аппаратное обеспечение, которое имеет свободные драйверы и прошивки. Сегодня широкий список наличествующей аппаратуры поддерживается GNU/Linux-libre — от клавиатур и графических карт до сканеров и контроллеров Ethernet. К сожалению, всё ещё остаётся ряд производителей железа, которые запрещают пользователям управлять их устройствами, и такое аппаратное обеспечение не поддерживается системой Guix.

Основной областью, в которой отсутствуют свободные драйверы и прошивки, являются устройства Wi-Fi. Работают устройства Wi-Fi, которые используют платы Atheros (AR9271 и AR7010) и взаимодействуют с драйвером Linux-libre ath9k, также использующие платы Broadcom/AirForce (BCM43xx with Wireless-Core Revision 5), которые работают с драйвером Linux-libre b43-open. Свободная прошивка существует для обоих и доступна в системе Guix из коробки как часть %base-firmware (see firmware).

Фонд свободного программного обспечения FSF ведёт Уважение вашей свободы (RYF) — программу сертификации аппаратного обеспечения, которое уважает вашу свободу и вашу безопасность и утверждает, что вы имеете контроль над вашими устройствами. Мы побуждаем вас проверить список устройств, сертифицированных RYF.

Другой полезный ресурс — сайт H-Node. Он содержит каталог устройств с информацией об их поддержке в GNU/Linux.


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.3 Установочная флеш и DVD

Установочный образ ISO-9660 может быть записан на USB-флеш или DVD, скачать его можно по адресу: ‘https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0.system.iso’, где system одна из следующих:

x86_64-linux

для системы GNU/Linux на 64-битных Intel/AMD-совместимых процессорах;

i686-linux

для системы GNU/Linux на 32-битных Intel-совместимых процессорах.

Обязательно скачайте связанный файл подписи .sig и проверьте аутентичность образа так:

$ wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.x86_64-linux.iso.sig
$ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig

Если это завершается ошибкой, значит у вас нет необходимого публичного ключа, тогда запустите команду для импорта ключа:

$ wget https://sv.gnu.org/people/viewgpg.php?user_id=127547 \
      -qO - | gpg --import -

и запустите команду gpg --verify.

Обратите внимание, что предупреждение по типу «Этот ключ не сертифицирован с доверенной подписью!» является нормальным.

Этот образ содержит инструменты, необходимые для установки. Он должен копироваться как есть на большую USB-флеш или DVD.

Запись на USB-флеш

Вставьте в компьютер USB-флеш объёмом 1 Гб или более и определите его имя. Учитывая имя (обычно соответствующее /dev/sdX) скопируйте образ на него:

dd if=guix-system-install-1.3.0.x86_64-linux.iso of=/dev/sdX status=progress
sync

Доступ к /dev/sdX обычно требует привилегий root.

Запись на DVD

Вставьте чистый DVD в компьютер и определите имя устройства. Обычно DVD определяется как /dev/srX, скопируйте образ так:

growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.3.0.x86_64-linux.iso

Доступ к /dev/srX обычно требует привилегий root.

Загрузка

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. In order to boot from Libreboot, switch to the command mode by pressing the c key and type search_grub usb.

Смотрите See Установка Guix на виртуальную машину, если вы хотите установить систему Guix на виртуальную машину (VM).


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.4 Подготовка к установке

Once you have booted, you can use the guided graphical installer, which makes it easy to get started (see Графическая установка в GUI). Alternatively, 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 Ручная установка).

Графическа установка доступна в TTY1. Вы можете запустить оболочку root в TTY 3-6, нажимая ctrl-alt-f3, ctrl-alt-f4 и т.д. TTY2 отображает эту документацию, открыть его можно клавишами ctrl-alt-f2. Листать документацию можно командами просмотрщика Info (see Stand-alone GNU Info). Установка системы запускает демона мыши GPM, который позволяет вам выделять текст лековй кнопкой мыши и вставлять средней кнопкой.

Примечание: Установка требует доступа к Интернету, чтобы скачивать любые отсутствующие зависимости в вашей конфигурации системы. Смотрите раздел "Сеть" ниже.


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.5 Графическая установка в GUI

Графический установщик представляет собой текстовый интерфейс. Он взаимодействует через диалоговые блоки, проходя шаги установки системы GNU Guix.

Первый диалоговый блок позволяет вам установить систему в таком виде, как во время установки. Вы можете выбрать язык, раскладку клавиатуры, задать настройки сети для установки. На картинке ниже — диалог настройки сети.

networking setup with the graphical
installer

Следующие шаги позволят вам разметить диск, как это показано на картинке ниже. Также можно выбрать шифрование вайловой системы (или без шифрования), ввести имя хоста и пароль root, создать дополнительную учётную запись и другие действия.

partitioning with the graphical
installer

Отметим, что в любое время установщик позволяет вам отменить текущий шаг и вернуться к предыдущему шагу установки, как это показано на картинке ниже.

resuming the installation process

Когда настройки выполнены, установщик сгенерирует конфигурацию операционной системы и отобразит её (see Использование системы конфигурации). На этом этапе нажатие “OK” запустит установку. После успешнго завершения нужно перезагрузиться и использовать новую систему. Смотрите See После установки системы, чтобы узнать ещё больше!


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.6 Ручная установка

Этот раздел описывает, как можно вручную установить систему GNU Guix на вашу машину. Это потребует знаний GNU/Linux, оболочки и инструментов администрирования. Если вы считаете, это не для вас, используйте вариант графической установки (see Графическая установка в GUI).

Во время установки доступна оболочка root в TTY от 3 до 6. Нажмите ctrl-alt-f3, ctrl-alt-f4 и т.д., чтобы переключиться на них. Они имеют много стандартных инструментов для установки системы. Но это также работающая система Guix, а это значит, что вы можете установить дополнительные пакеты, которые потребуются, используя guix package (see Вызов guix package).


Next: , Up: Ручная установка   [Contents][Index]

3.6.1 Раскладка клавиатуры, Сеть, Разметка диска

Перед установкой системы вам может понадобиться смена раскладки клавиатуры, а также настройка сети и разметка целевого жёсткого диска. В этом разделе приведены соответствующие инструкции.

3.6.1.1 Раскладка клавиатуры

Установочный образ использует раскладку клавиатуры US qwerty. Если нужно поменять её, можно пользоваться командой loadkeys. Например, следующая команда выбирает раскладку клавиатуры Dvorak:

loadkeys dvorak

Смотрите файлы в /run/current-system/profile/share/keymaps, чтобы найти список доступных раскладок. Запустите man loadkeys, чтобы узнать больше.

3.6.1.2 Сеть

Запустите следующую команду, чтобы узнать имена сетевых интерфейсов:

ifconfig -a

… или используйте специальную команду GNU/Linux ip:

ip address

Проводные интерфейсы называются на букву ‘e’; например, интерфейс, соответствующий первому контроллеру Ethernet на материнской плате, называется ‘eno1’. Беспроводные интерфейсы имеют имена, начинающиеся с ‘w’, как ‘w1p2s0’.

Проводное соединение

Чтобы настроить проводную сеть, запустите следующую команду, заменив interface именем проводного интерфейса, который вы хотите использовать.

ifconfig interface up

… или используйте специальную команду GNU/Linux ip:

ip link set interface up
Беспроводное соединение

Чтобы настроить беспроводную сеть, можно создать конфигурционный файл для wpa_supplicant (расположение файла неважно). Можно пользоваться любым доступным текстовым редактором, например, nano:

nano wpa_supplicant.conf

Следующий пример настроек подойдёт для большинства беспроводных сетей. Нужно предоставить фактический SSID и парольную фразу для сети, к которой вы подключаетесь:

network={
  ssid="my-ssid"
  key_mgmt=WPA-PSK
  psk="the network's secret passphrase"
}

Запустите сервис беспроводной сети в фоновом режиме следующей командой (замените interface именем сетевого интерфейса, который вы используете):

wpa_supplicant -c wpa_supplicant.conf -i interface -B

Запустите man wpa_supplicant, чтобы узнать больше.

Теперь нужно получить IP-адрес. В случае сети, где IP-адреса автоматически распределяются с помощью DHCP, можно запустить:

dhclient -v interface

Попробуйте пинговать сервер, чтобы узнать, работает ли сеть:

ping -c 3 gnu.org

Настройка доступа к сети необходима почти всегда, потому что ораз может не иметь программное обеспечение и инструменты, которые могут понадобиться.

Если вам нужено настроить доступ HTTP и HTTPS прокси, выполните следующую команду:

herd set-http-proxy guix-daemon URL

где URL адрес прокси, например http://example.org:8118.

Если желаете, вы можете продолжить установку удалённо, запустив SSH-сервер:

herd start ssh-daemon

Не забудьте задать пароль командой passwd или настроить публичный ключ OpenSSH для аутентификации, чтобы иметь возможность подключиться.

3.6.1.3 Разметка диска

Если это ещё не сделано, тогда нужно разделить диск, а затем отформатировать целевой(-ые) раздел(ы).

Установочный образ содержит несколько инструментов для разметки, включая Parted (see Overview in GNU Parted User Manual), fdisk и cfdisk. Запустите и настройте ваш диск, используя план разметки, который нужен:

cfdisk

Если ваш диск использует формат GUID Partition Table (GPT), и вы планируете использовать GRUB, работающий с BIOS (что по умолчанию), убедитесь, что раздел BIOS Boot Partition доступен (see BIOS installation in GNU GRUB manual).

Если вместо этого вы хотите использовать GRUB, работающий с EFI, тогда необходима разметка система EFI FAT32 (ESP). Такая разметка может, например, монтироваться в /boot/efi и должна иметь флаг esp. То есть в случае parted:

parted /dev/sda set 1 esp on

Примечание: Не уверенны, что выбрать: GRUB, взаимодействующий с EFI или BIOS? Если существует директория /sys/firmware/efi в установочом образе, тогда вам следует использовать установку EFI и grub-efi-bootloader. В противном случае нужно использовать GRUB, работающий с BIOS, называемый grub-bootloader. Смотрите See Настройка загрузчика для большей информации о загрузчиках.

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

Для корневой файловой системы наиболее широко используется формат ext4. Другие файловые системы, такие как Btrfs, поддерживают сжатие, которое, как известно, прекрасно дополняет дедупликацию файлов, которую демон выполняет независимо от файловой системы (see deduplication).

Желательно добавить метки файловых систем, чтобы вы могли ссылаться на них по именам в объявлениях file-system (see Файловые системы). Обычно это можно сделать опцией -L в mkfs.ext4, например. Допустим, раздел root располагается в /dev/sda2, можно добавить метку my-root следующим образом:

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

Когда это сделано, монтируйте целевую файловую систему под /mnt следующей командой (опять же полагая, что метка раздела root — my-root):

mount LABEL=my-root /mnt

Также монтируйте любые другие файловые системы внутрь целевой файловой системы. Если например, выбрана точка монтирования EFI /boot/efi, монтируйте её в /mnt/boot/efi, так, чтобы она обнаруживалась после запуска guix system init.

Наконец, если вы планируете использовать один или более разделов swap (see swap space in The GNU C Library Reference Manual), обязательно инициируйте их командой mkswap. Допустим, если ваш раздел swap размещён в /dev/sda3, нужно выполнить:

mkswap /dev/sda3
swapon /dev/sda3

Возможно, вместо этого вы используете swap-файл. Например, предположим, вы хотите использовать в новой системе swap-файл в /swapfile, тогда нужно выполнить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

Заметим, что если вы шифруете раздел root и создаёте swap-файл в его файловой системе, как это описано выше, шифрование также будет защищать swap-файл, как и любой другой файл в этой файловой системе.


Previous: , Up: Ручная установка   [Contents][Index]

3.6.2 В продолжении установки

Когда целевые разделы готовы и раздел root монтирован под /mnt, всё готово для старта. Сначала запустите:

herd start cow-store /mnt

Это сделает /gnu/store копируемым при записи (copy-on-write), что заставит систему записывать пакеты, добавляемые в систему на этапе установки, на целевой диск под /mnt, а не держать их в памяти. Это важно, потому что по команде guix system init (смотрите ниже) будут скачиваться или собираться пакеты в /gnu/store, которая изначально находится в файловой системе, загрузженной в память.

Далее нужно редактировать файл объявления операционной системы, которым будет пользоваться установщик. Для этого при установке системы можно использовать три текстовых редактора. Мы ркомендуем GNU nano (see GNU nano Manual) — он поддерживает подсветку синтаксиса и работу со скобками. Другие редакторы: GNU Zile (клон Emacs), nvi (клон исходного редактора BSD vi). Мы настойчиво рекомендуем сохранять файл конфигураций в целевой файловой системе root, например, как /mnt/etc/config.scm. Иначе есть возможность потерять конфигурационный файл, когда вы загрузитесь в новую установенную систему.

Смотрите See Использование системы конфигурации для подробностей о конфигурационном файле. Конфигурационный файл для примера доступен под /etc/configuration установочного образа. Например, чтобы получить систему с графическим сервером (т.е. десктопную систему), можно это сделать примерно так:

# mkdir /mnt/etc
# cp /etc/configuration/desktop.scm /mnt/etc/config.scm
# nano /mnt/etc/config.scm

Нужно уделить внимание содержимому конфигурационного файла, в частности:

Когда вы подготовили конфигурационный файл, нужно инициализировать новую систему (помните, что целевой раздел root монтирован под /mnt):

guix system init /mnt/etc/config.scm /mnt

Это копирует все нужные файлы и устанавливает GRUB в /dev/sdX, если конечно, вы не задали опцию --no-bootloader. Подробнее - see Вызов guix system. Эта команда может вызывать скачивание или сборку отсутствующих пакетов, что может занять время.

Когда эта команда завершена, надеемся, успешно, можно запустить reboot и загрузиться в новую систему. Пароль root в новой системе изначально пустой; пароли других пользователей должны быть заданы командой passwd от root, если конечно, ваша конфиурация не содержит указания (see user account passwords). Смотрите See После установки системы, чтобы узнать, что дальше!


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.7 После установки системы

Замечательно! Теперь вы загрузились в систему Guix! Теперь можно обновить систему, когда у вас будет на это время, запустив, например:

guix pull
sudo guix system reconfigure /etc/config.scm

Это соберёт поколение (generation) системы с последними пакетами и сервисами (see Вызов guix system). Мы рекомендуем делать это регулярно, чтобы ваша система содержала обновления безопасности (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 ….

The difference matters here, because guix pull updates the guix command and package definitions only for the user it is run as. This means that if you choose to use guix system reconfigure in root’s login shell, you’ll need to guix pull separately.

Now, see Начиная, and join us on #guix on the Libera Chat IRC network or on guix-devel@gnu.org to share your experience!


Next: , Previous: , Up: Установка системы   [Contents][Index]

3.8 Установка Guix на виртуальную машину (VM)

Если вы хотите установить систему Guix на виртуальную машину (VM) или на виртуальный приватный сервер (VPS) вместо вашей любимой машины, этот раздел для вас.

To boot a QEMU VM for installing Guix System in a disk image, follow these steps:

  1. Во-первых, найдите и распакуйте установочный образ системы Guix, как описано ранее (see Установочная флеш и DVD).
  2. Создайте образ диска, который будет содержать установленную систему. Чтобы создать образ диска qcow2, используйте команду qemu-img:
    qemu-img create -f qcow2 guix-system.img 50G
    

    Результирующий файл будет намного меньше 50Гб (обычно менее 1Мб), но он будет увеличиваться с заполнение виртуального устройства.

  3. Загрузите установочный образ USB в VM:
    qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
      -nic user,model=virtio-net-pci -boot menu=on,order=d \
      -drive file=guix-system.img \
      -drive media=cdrom,file=guix-system-install-1.3.0.system.iso
    

    -enable-kvm опционален, но значительно улучшает производительность, see Запуск Guix на виртуальной машине.

  4. Теперь вы в корне VM, проделайте процесс установки See Подготовка к установке и последующие инструкции.

Once installation is complete, you can boot the system that’s on your guix-system.img image. See Запуск Guix на виртуальной машине, for how to do that.


Previous: , Up: Установка системы   [Contents][Index]

3.9 Сборка установочного образа

Установочный образ, описанный выше, собран командой guix system, а именно:

guix system image -t iso9660 gnu/system/install.scm

Нужно просмотреть gnu/system/install.scm в дереве исходников, а также Вызов guix system, чтобы получить больше информации об установочном образе.

3.10 Сбрка и установка образа для плат ARM

Многие платы ARM требуют специфический вариант загрузчика U-Boot.

Если вы собираете образ диска, а загрузчик не доступен (на другом устройстве загрузке и т.п.), советуем собрать образ, который включает загрузчик, то есть так:

guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 — это имя материнской платы. Если вы обозначите недействительную плату, будет выведен список возможных плат.


Next: , Previous: , Up: Top   [Contents][Index]

4 Начиная

Предположительно, вы попали в этот раздел, потому что либо вы установили Guix поверх другого дистрибутива (see Установка), либо вы установили отдельную операционную систему Guix (see Установка системы). Пора вам начать использовать Guix, и этот раздел призван помочь вам в этом.

Guix занимается установкой программного обеспечения, поэтому, вероятно, первое, что вам нужно сделать, это поискать программное обеспечение. Допустим, вы ищете текстовый редактор, вы можете запустить:

guix search text editor

Эта команда показывает количество подходящих пакетов, каждый раз показывая имя пакета, версию, описание и дополнительную информацию. Как только вы определились с тем, какой пакет хотите использовать, скажем, Emacs (ха!), вы можете установить его следующей командой (запустите эту команду как обычный пользователь, root привилегии не нужны!):

guix install emacs

You’ve installed your first package, congrats! The package is now visible in your default profile, $HOME/.guix-profile—a profile is a directory containing installed packages. In the process, you’ve probably noticed that Guix downloaded pre-built binaries; or, if you explicitly chose to not use pre-built binaries, then probably Guix is still building software (see Подстановки, for more info).

Пока вы используете Guix System, guix install команда должна выводить данную подсказку:

hint: Consider setting the necessary environment variables by running:

     GUIX_PROFILE=\"$HOME/.guix-profile\"
     . \"$GUIX_PROFILE/etc/profile\"

Или смотрите `guix package --search-paths -p "$HOME/.guix-profile"'.

Действительно, теперь вы должны указать своей оболочке, где находятся emacs и другие программы, установленные вместе с Guix. Вставка двух строк добавит $HOME/.guix-profile/bin (там где находится установленный пакет) в переменную окружения PATH. Вы можете вставить эти две строки в свою оболочку, чтобы они сразу вступили в силу, но, что более важно, вы должны добавить их в ~/.bash_profile (или аналогичный файл, если вы не используете Bash), чтобы переменные среды устанавливались в следующий раз, когда вы создаете оболочку. Вам нужно сделать это только один раз, и другие переменные среды путей поиска будут обработаны аналогичным образом. Например, если вы установите python или библиотеки Python, PYTHONPATH будет определена.

Вы можете продолжать установку пакетов по своему желанию. Чтобы вывести список установленных пакетов, запустите:

guix package --list-installed

Для удаления пакета вы можете выполнить команду guix remove. Отличительная черта - возможность откатить любую операцию, которую вы сделали (установка, удаление, обновление):

guix package --roll-back

Каждая операция фактически является транзакцией, которая создает новое поколение. Эти поколения и разницу между ними можно отобразить, запустив:

guix package --list-generations

Теперь вы знаете основы управления пакетами!

Больше информации: See Управление пакетами, для получения дополнительной информации об управлении пакетами. Вам может понравиться декларативное управление пакетами с помощью guix package --manifest, управление отдельными профилями с помощью --profile, удаление старых поколений, сбор мусора и другие полезные функции, которые помогут пригодится по мере того, как вы ближе познакомитесь с Guix. Если вы разработчик, see Разработка для получения дополнительных инструментов. И если вам интересно, see Особенности, чтобы заглянуть под капот.

После того, как вы установили набор пакетов, вам нужно будет периодически обновлять их до последней и самой лучшей версии. Для этого вы сначала загрузите последнюю версию Guix и его коллекцию пакетов:

guix pull

Конечным результатом является новая команда guix в ~/.config/guix/current/bin. Если вы не используете Guix System, при первом запуске guix pull обязательно следуйте подсказке, которую выводит команда, и, подобно тому, что мы видели выше, вставьте эти две строки в свой терминал и .bash_profile:

GUIX_PROFILE="$HOME/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"

Вы также должны указать своей оболочке, чтобы она указывала на новую команду guix:

hash guix

На данный момент вы используете новый Guix. Вы можете обновить все ранее установленные пакеты:

guix upgrade

Когда вы запустите эту команду, вы увидите, что загружены двоичные файлы (или, возможно, собраны некоторые пакеты), и в конечном итоге вы получите обновленные пакеты. Если один из этих обновленных пакетов вам не понравится, помните, что вы всегда можете выполнить откат!

Вы можете отобразить точную версию Guix, которую сейчас используете, запустив:

guix describe

Отображаемая информация - это все, что нужно для воспроизведения того же самого Guix, будь то в другой момент времени или на другой машине.

Больше информации: See Запуск guix pull, для дополнительной информации. See Каналы, как указать дополнительные каналы для получения пакетов, как реплицировать Guix и т. д. Также команда time-machine может оказаться полезной (see Вызов guix time-machine).

Если вы установили Guix System, первое, что вам нужно сделать, это обновить вашу систему. После того, как вы запустите команду guix pull, чтобы получить последнюю версию Guix, вы можете обновить систему следующим образом:

sudo guix system reconfigure /etc/config.scm

По завершении в системе будут запущены последние версии пакетов. Когда вы перезагрузите машину, вы заметите подменю в загрузчике “Old system generations”: это то, что позволяет вам загружать старшее поколение вашей системы, если последнее поколение “сломано” или не соответствует вашим ожиданиям. Как и в случае с пакетами, вы всегда можете откатиться на предыдущее поколение всей системы:

sudo guix system roll-back

Есть много вещей, которые вы, вероятно, захотите настроить в своей системе: добавление новых учетных записей пользователей, добавление новых системных служб, изменение конфигурации этих служб и т.д. Конфигурация системы полностью определена в файле /etc/config.scm. See Использование системы конфигурации, узнать о настройке системы.

Теперь вы знаете достаточно, чтобы начать!

Ресурсы: Остальная часть этого руководства представляет собой справочник по всему, что связано с Guix. Вот несколько дополнительных ресурсов, которые могут вам пригодиться:

Мы надеемся, что вам понравится Guix так же, как и сообществу нравится его создавать!


Next: , Previous: , Up: Top   [Contents][Index]

5 Управление пакетами

Целью GNU Guix является предоставление пользователям возможности легко устанавливать, обновлять и удалять пакеты программного обеспечения, без необходимости изучения процедур их сборки и без необходимости разрешения зависимостей. Также Guix имеет следующие обязательные особенности.

Этот раздел описывает основные особенности Guix и предоставляемые им инструменты управления пакетами. Кроме интерфейса командной строки, который описан ниже (see guix package), можно также использовать интерфейс Emacs-Guix (see The Emacs-Guix Reference Manual), если установить пакет emacs-guix (выполните команду M-x guix-help, чтобы начать работу с ним):

guix install emacs-guix

Next: , Up: Управление пакетами   [Contents][Index]

5.1 Особенности

Здесь мы предполагаем, что вы уже сделали свои первые шаги с Guix (see Начиная) и хотели бы получить обзор того, что происходит под капотом.

При использовании Guix каждый пакет после установки размещается в package store, в собственной директории, например, /gnu/store/xxx-package-1.2, где xxx - это строка base32.

Вместо того, чтобы ссылаться на эти директории, пользователям нужно обращаться к их профилям, профиль указывает на пакеты, которые они хотят использовать. Эти профили хранятся в домашней директории каждого пользователя в $HOME/.guix-profile.

Например, alice устанавливает GCC 4.7.2. В результате /home/alice/.guix-profile/bin/gcc указывает на /gnu/store/…-gcc-4.7.2/bin/gcc. Допустим, на той же машине bob установил GCC 4.8.0. Профиль пользователя bob просто указывает на /gnu/store/…-gcc-4.8.0/bin/gcc. То есть обе версии GCC присутствуют в одной системе без помех.

Команда guix package — главный инструмент для управления пакетами (see Вызов guix package). Она работает с профилями пользователей, которые имеют права обычных пользователей.

Команда предоставляет обязательные операции установки, удаления и обновления. Каждый вызов представляет собой транзакцию, независимо от того, выполнены успешно заданные операции, или ничего не произошло. Так, если процесс guix package завершился во время транзакции, или произошёл сбой питания во время транзакции, тогда профиль пользователя остаётся в исходном состоянии, готовом к использованию.

В дополнение, каждую транзакцию, которая работает с пакетами, можно откатить. Так если, например, обновление устанавливает новую версию пакета, которая имеет серьёзный баг, пользователи могут откатиться до предыдущей инстанции своего профиля, который работал нормально. Точно так же, глобальные настройки системы Guix являются объектом транзакционных обновлений и откатов (see Использование системы конфигурации).

Все пакеты на складе могут быть собраны как мусор. Guix может определить, какие пакеты всё ещё используются профилями пользователей, и удалить те, которые однозначно больше не используются (see Вызов guix gc). Также пользователи могут явно удалить старые поколения (generations) их профилей, поэтому пакеты, на которые ссылались старые профили, могут быть удалены.

Guix реализует чисто функциональный подход к управлению пакетами, как описано во введении (see Введение). В /gnu/store имя директории каждого пакета содержит хеш всех входных данных, которые использовались при сборке пакета: компилятор, библиотеки, скрипты сборки и т.д. Это прямое соответствие позволяет пользователям убедиться, что данная установка пакета соответствует текущему состоянию дистрибутива. Также это помогает улучшить воспроизводимость сборки: благодаря изолированному окружению сборки, которая используется при установке пакета, результат сборки содержит точно такие же файлы на разных машинах (see container).

Эта концепция позволяет Guix поддерживать прозрачное внедрение бинарников/исходников. Когда доступен элемент /gnu/store, собранный заранее на внешнем источнике, то есть готова подстановка, Guix просто скачивает и распаковывает его. В противном случае он собирает пакет из исходников на локальной машине (see Подстановки). Так как результаты сборки обычно воспроизводимы бит-к-биту, пользователи не должны доверять серверам, которые поставляют подстановки — они могут целенаправленно запросить локальную сборку и не пользоваться серверами подстановки (see Запуск guix challenge).

Управление окружением сборки — функция, которая полезна для разработчиков. Команда guix environment позволяет разработчикам пакетов быстро установить требуемое окружение разработки без необходимости устанавливать в свой профиль зависимости пакета вручную (see Запуск guix environment).

Guix и его определения пакетов подчняются контролю версиями, и guix pull позволяет "путешествовать во времени" по истории Guix (see Запуск guix pull). Это позволяет повторять инстанцию Guix на разных машинах или по прошествию времени, что в свою очередь позволяет вам повторять полностью программное окружение из достпуных трекеров источников программного обеспечения.


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.2 Вызов 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. These operations work on a user profile—a directory of installed packages. Each user has a default profile in $HOME/.guix-profile. The command operates only on the user’s own profile, and works with normal user privileges (see Особенности). Its syntax is:

guix package options

В первую очередь, options (опции) задают операции, которые нужно выполнить в транзакции. По завершении создаётся новый профиль, а предыдущие поколения (generations) профиля остаются доступными, если пользователь решит откатиться.

Например, чтобы удалить lua и устанвоить guile и guile-cairo в одной транзакции, напечатайте:

guix package -r lua -i guile guile-cairo

Для вашего удобства мы также предоставляем следующие синонимы:

Эти синонимы не такие мощные, как guix package, и предоставляют меньше опций, так что в некоторых случаях вам скорее нужно пользоваться непосредственно guix package.

guix package также поддерживает декларативный подход, с помощью которого пользователь зааёт точный набор пакетов, которые должны быть доступны, и передаёт его в опции --manifest (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. Если вы не используете систему Guix, предполагается добавление следующих строк в ваш ~/.bash_profile (see Bash Startup Files in The GNU Bash Reference Manual), чтобы порождаемые оболочки получили все необходимые определения переменных окружения:

GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$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.

Опции options могут быть следующими:

--install=package
-i package

Установить заданный пакет.

Каждый package может задавать простое имя пакета, как например, guile, или имя пакета с указанием номера версии, например, guile@1.8.8 или просто guile@1.8 (в последнем случае выбирается самая новая версия с префиксом 1.8).

Если не задан номер версии, тогда будет выбрана самая новая доступная версия. Добавм, что package может содержать двоеточие и одно имя выходных данных пакета, как gcc:doc или binutils@2.22:lib (see Пакеты со множественным выходом). Пакеты с соответствующим именем (и опционально, версией) будут отыскиваться в модулях дистрибутива GNU (see Пакетные модули).

Иногда пакеты имеют распространённые входные данные (propagated inputs) — это зависимости, которые устанавливаются автоматически вместе с требуемыми пакетами (см. see propagated-inputs in package objects для подробной информации о распространяемых входных днных в определениях пакетов).

Примером является библиотека GNU MPC: его файлы заголовков C ссылаются на файлы библиотеки GNU MPFR, которые в свою очередь, ссылаются на библиотеку GMP. Так при установке MPC, также в профиль будут устанволены библиотеки MPFR и GMP; удаление MPC также удалит MPFR и GMP, если конечно, они не были явно установлены пользователем.

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

Устанавить пакет, соответствующий exp.

exp должно быть выражением Scheme, которое определяет объект <package>. Эта опция полезна, чтобы указать однозначно пакет, который имеет схожие варианты имён, например, выражением (@ (gnu packages base) guile-final).

Отметим, что эта опция устанавливает первое содержимое пакета, чего может быть недостаточно, если нужен специфичный выход пакета со множественным выходом.

--install-from-file=file
-f file

Устанавить пакет, который определён в файле.

Например, file может содержать определение (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+))

Пользователи могут найти полезным включить подобный файл guix.scm в корень дерева своего проекта исходного кода, и он будет использоваться для тестирования разработки снепшотов и для создания воспроизводимого окружения разработки (see Запуск guix environment).

file может также содержать JSON-представление одного или нескольких определений пакетов. Запуск guix package -f на файле hello.json со следующим содержимым, установит пакет greeter после сборки myhello:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    }
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "https://example.com/greeter-1.0.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false,
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]
--remove=package
-r package

Удалить обозначенный пакет.

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 regexps are specified, upgrade only installed packages whose name matches a regexp. Also see the --do-not-upgrade option below.

Отметим, что это обновляет пакеты, которые установлены в системе, до последних версий, имеющихся в дистрибутиве. Чтобы обновить дистрибутив, нужно регулярно запускать guix pull (see Запуск guix pull).

При обновлении автоматически применяются преобразования пакета, которые были первоначально применены при создании профиля (see Параметры преобразования пакета). Например, предположим, что вы сначала установили Emacs из ветки разработки с помощью:

guix install emacs-next --with-branch=emacs-next=master

В следующий раз, когда вы запустите guix upgrade, Guix снова посмотрит на ветку разработки Emacs и соберет новый emacs-next.

Обратите внимание, что параметры преобразования, такие как --with-branch и --with-source, зависят от внешнего состояния; вам решать, чтобы они работали должным образом. Вы также можете отменить преобразования, которые применяются к пакету, запустив:

guix install package
--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

Создаёт новую версию профиля из объекта манифеста, возвращаемого кодом Scheme в 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 должен возвращать объект manifest, который, грубо говоря, является списком пакетов:

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Use a specific package output.
       (list guile-2.0 "debug")))

В этом примере мыдолжны знать, какие модули содержат определения переменных emacs и guile-2.0, чтобы написать правильную строку use-package-modules, что может быть затруднительно. Вместо этого мы можем обозначить обычные спецификации пакетов и сделать, чтобы specifications->manifest искал соответствующие объекты пакетов так:

(specifications->manifest
 '("emacs" "guile@2.2" "guile@2.2:debug"))

See --export-manifest, чтобы узнать, как получить файл манифеста из существующего профиля.

--roll-back

Откатиться до предыдущего поколения профиля, то есть отменить последнюю транзакцию.

When combined with options such as --install, roll back occurs before any other actions.

При откате от первого поколения, которое по факту содержит установленные пакеты, профиль будет указывать на нулевое поколение, которое не содержит файлы, кроме собственных метаданных.

После выполнения отката, установка, удаление или обновление пакетов по факту заменяет прежние будущие поколения. То есть история поколений в профиле всегда линейная.

--switch-generation=pattern
-S pattern

Переключиться на определённое поколение, опрделённое 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]

Вывести отчёт об определениях переменных окружения в синтаксисе Bash. Это может понадобиться для использования набора установленных пакетов. Эти переменные окружения используются некоторыми установленными пакетами для поиска файлов.

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.

Обычный способ определить эти переменные окружения в оболочке:

$ eval `guix package --search-paths`

Вид kind может быть либо точный адрес exact, либо префикс prefix, либо суффикс suffix, то есть возвращаемые переменные окружения могут быть либо точными, либо префиксами и суффиксами текущего значения этих переменных. При пропуске вид kind по умолчанию выбирается точный exact.

Эта опция также может использоваться для вычисления комбинированных путей поиска нескольких профилей. Рассмотрим пример:

$ 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

Использовать profile вместо пользовательского профиля по умолчанию.

profile должен быть именем файла, который будет создан по завершении. Конкретно profile будет простой символической ссылкой (“символическая ссылка”), указывающей на текущий профиль, в котором установлены пакеты:

$ guix install hello -p ~/code/my-profile
…
$ ~/code/my-profile/bin/hello
Hello, world!

Чтобы избавиться от профиля, нужно удалить символическую ссылку и привязанные к ней элементы, которые указывают на конкретные поколения:

$ rm ~/code/my-profile ~/code/my-profile-*-link
--list-profiles

Перечислить все профили пользователя:

$ guix package --list-profiles
/home/charlie/.guix-profile
/home/charlie/code/my-profile
/home/charlie/code/devel-profile
/home/charlie/tmp/test

При запуске от имени root будут перечислены все профили всех пользователей.

--allow-collisions

Разрешить соперничающие пакеты в новом профиле. Используйте на свой собственный страх и риск!

По умолчанию guix package делает отчёт о противоречиях collisions в профиле. Противоречия происходят, когда дви или более разных версии или варианта данного пакета присутсвуют в профиле.

--bootstrap

Использовать бутстрап Guile для сборки профиля. Эта опция полезна только разработчикам дистрибутива.

В дополнение к этим действиям guix package поддерживает следующие опции при обращении к текущему состоянию профиля или для проверки доступности пакетов:

--search=regexp
-s regexp

Вывести список пакетов, чьи имена или описания содержат выражение regexp с учётом регистра, упорядоченные по соответствию. Печать всех метаданных соответствующих пакетов в формате recutils (see GNU recutils databases in GNU recutils manual).

Это позволяет извлекать заданые поля, используя команду recsel, например:

$ 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

Также для отображения имён всех доступных пакетов под лицензией GNU LGPL версии 3:

$ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
name: elfutils

name: gmp
…

Также можно уточнить поиск, используя несколько флагов -s в команде guix package или несколько аргументов в guix search. Например, следующая команда возвращает список настольных игр (используя синоним guix search на этот раз):

$ guix search '\<board\>' game | recsel -p name
name: gnubg
…

При пропуске -s game мы получим пакеты программного обеспечения, которые работают с печатными платами (boards); удалив угловые скобки рядом с board, получим пакеты, которые также работают с клавиатурами (keyboards).

А теперь более запутанный пример. Следующая команда ищет библиотеки криптографии, фильтрует библиотеки Haskel, Perl, Python и Ruby и печатает имена и краткие описания найденных пакетов:

$ guix search crypto library | \
    recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

См. See Selection Expressions in GNU recutils manual для подробной информации о регуларяных выражениях selection expressions для recsel -e.

--show=package

Показать детали пакета package из списка доступных пакетов в формате recutils (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

Можно также указать полное имя пакета, чтобы только получить детали его определённой версии (в этот раз, используя guix show псевдоним):

"$ guix show python@3.4 | recsel -p name,version"
"name: python"
"version: 3.4.3"
--list-installed[=regexp]
-I [regexp]

Вывести текущий список установленных пакетов в заданном профиле, отобразив самый последний установленный пакет последним. Если задано regexp, будут выведены только пакеты, чьи имена содержат regexp.

Для каждого установленного пакета выводит следующие элементы, разделенные табуляцией (tab): имя пакета, строка версии, частью какого пакета является установленный пакет (например, out вывода по умолчанию включает include его заголовки т.д.), а также путь этого пакета на складе.

--list-available[=regexp]
-A [regexp]

List packages currently available in the distribution for this system (see Дистрибутив GNU). When regexp is specified, list only available packages whose name matches regexp.

Для каждого пакета выводит следующие элементы, разделённые табуляцией: его имя, строка версии, часть пакета (see Пакеты со множественным выходом), а также расположение его определения в исходниках.

--list-generations[=pattern]
-l [pattern]

Вывести список поколений (generations) с датами их создания; для каждого поколения отобразить установленные пакеты, самый последний установленный пакет отобразать последним. Отметим, что нулевое поколение никогда не показывается.

Для каждого установленного пакета отображает следующие элементы, разделённые табуляцией: имя пакета, строка версии, частью какого пакета является установленный пакет (see Пакеты со множественным выходом), а также расположение пакета на складе.

Если используется pattern, команда выводит только соответствующие поколения. Правильные паттерны содержат:

--delete-generations[=pattern]
-d [pattern]

Если pattern пропущен, удалит все поголения, кроме текущего.

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.

Если текущее поколение попадает под условия паттерна, оно не будет удалено. А также нулевое поокление никогда не удаляется.

Отметим, что удаление поколений делает невозможным откат к ним. Следовательно эта команда должна использоваться внимательно.

--export-manifest

Напишите в стандартный вывод манифест, подходящий для --manifest, соответствующий выбранному профилю (-ам).

Эта опция предназначена для того, чтобы помочь вам перейти из “императивного” режима работы—запустив guix install, guix upgrade и т.д.—в декларативный режим, который предлагает --manifest.

Имейте в виду, что полученный манифест приблизительно соответствует тому, что на самом деле содержится в вашем профиле; например, в зависимости от того, как был создан ваш профиль, он может относиться к пакетам или версиям пакетов, которые не совсем то, что вы указали.

Имейте в виду, что манифест является чисто символическим: он содержит только имена пакетов и, возможно, версии, и их значение со временем меняется. Если вы хотите “привязать” каналы к ревизиям, которые использовались для создания профиля (ов), см. --export-channels ниже.

--export-channels

Вывести на стандартный вывод список каналов, используемых выбранным профилем (-ями), в формате, подходящем для guix pull --channels или guix time-machine --channels (see Каналы).

Вместе с --export-manifest этот параметр предоставляет информацию, позволяющую копировать текущий профиль (see Копирование Guix).

Однако обратите внимание, что выходные данные этой команды приблизительно используются для создания этого профиля. В частности, один профиль мог быть построен из нескольких различных версий одного и того же канала. В этом случае --export-manifest выбирает последнюю версию и записывает список других ревизий в комментарий. Если вам действительно нужно выбрать пакеты из разных ревизий канала, вы можете использовать подчиненные элементы в своем манифесте для этого (see Младшие версии).

Если вы хотите перейти от “императивной” модели к полностью декларативной модели, состоящей из файла манифеста и файла каналов, закрепляющего точную желаемые версии каналов, то --export-manifest хорошая отправная точка.

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, and preserves them across upgrades (see Параметры преобразования пакета).


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.3 Подстановки

Guix поддерживает прозрачную развёртку исходников/бинарников, это означает возможность сборки пакетов локально или скачивания собранных элементов с сервера, или и то и другое. Мы называем собранные элементы подстановками (substitutes) — это подстановки результатов локальных сборок. Часто скасивание подстановки намного быстрее, чем сборка пакетов локально.

В качестве подстановок может выступать какой угодно результат сборки деривации (see Деривации). Конечно, обычно это собранные пакеты, но также архивы исходников, например, представляя собой результаты сборок дериваций, могут быть доступны в качестве подстановок.


Next: , Up: Подстановки   [Contents][Index]

5.3.1 Официальный сервер подстановок

Сервер ci.guix.gnu.org представляет собой интерфейс официальной фермы сборки, которая последовательно собирает пакеты Guix для некоторых архитектур и делает их доступными в качестве подстановок. Это источник подстановок по умолчанию; он может быть изменён при указании опции --substitute-urls как для guix-daemon (see guix-daemon --substitute-urls) так и для клиентских инструментов, как guix package (see client --substitute-urls option).

URL подстановок могут быть либо HTTP, либо HTTPS. Рекомендуется HTTPS, так как такая связь шифруется; и наоборот, использование HTTP делает связь видимой для подслушивающих, и они могут использовать собранную информацию, чтобы определить, например, что ваша система не имеет патчей, покрывающих уязвимости безопасности.

Подстановки из официальной фермы сборки доступны по умолчанию при использовании системы Guix (see Дистрибутив GNU). Однако они отключены по умолчанию при использовании Guix на чужом дистрибутиве, если конечно вы явно не включили их на одном из рекомендуемых шагов установки (see Установка). Ниже объясняется, как включить или отключить подстановки с официальной фермы сборки; такая же процедура может также использоваться для включения подстановок с любого другого сервера подстановок.


Next: , Previous: , Up: Подстановки   [Contents][Index]

5.3.2 Авторизация сервера подстановок

Чтобы разрешить Guix скачивать подстановки из ci.guix.gnu.org или зеркала, вы должны добавить его публичный ключ в список контроля доступа (ACL) импорта архивов, используя команду guix archive (see Вызов guix archive). Это действие означает, что вы доверяете ci.guix.gnu.org, что он не скомпрометирован и может давать подлинные подстановки.

Примечание: Если вы используете Guix System, вы можете пропустить этот раздел: Guix System разрешает замену из ci.guix.gnu.org по умолчанию.

Публичный ключ для ci.guix.gnu.org устанавливается вместе с Guix в prefix/share/guix/ci.guix.gnu.org.pub, где prefix — префикс установки Guix. Если вы установили Guix из исходников, проверьте подпись GPG guix-1.3.0.tar.gz, где содержится файл публичного ключа. Затем можно выполнить примерно следующее:

# guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub

Когда это сделано, вывод команды guix build должен измениться с примерно такого:

$ 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
…

на примерно следующий:

$ 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
…

The text changed from “The following derivations would be built” to “112.3 MB would be downloaded”. 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: , Up: Подстановки   [Contents][Index]

5.3.3 Получение заменителей с других серверов

Guix может искать и получать заменители с нескольких серверов. Это полезно, когда вы используете пакеты из дополнительных каналов, для которых официальный сервер не имеет заменителей, но их предоставляет другой сервер. Еще одна ситуация, когда это полезно, если вы предпочитаете выполнять загрузку с замещающего сервера вашей организации, прибегая к официальному серверу только в качестве запасного варианта или полностью отклоняя его.

Вы можете дать Guix список URL-адресов серверов с заменителями, и он проверит их в указанном порядке. Вам также необходимо явно авторизовать открытые ключи серверов с заменителями, чтобы Guix принял заменители, которые они подписывают.

В системе Guix это достигается путем изменения конфигурации службы guix. Поскольку служба guix является частью списков служб по умолчанию, %base-services и %desktop-services, вы можете использовать modify-services для изменения ее конфигурации и добавьте нужные URL-адреса и заменить ключи (see modify-services).

В качестве примера предположим, что вы хотите получить заменители из guix.example.org и авторизовать ключ этого сервера в дополнение к ci.guix.gnu.org. Полученная конфигурация операционной системы будет выглядеть примерно так:

(operating-system
  ;; …
  (services
    ;; Assume we're starting from '%desktop-services'.  Replace it
    ;; with the list of services you're actually using.
    (modify-services %desktop-services
      (guix-service-type config =>
                        (guix-configuration
                          (inherit config)
                          (substitute-urls
                            (append (list "https://guix.example.org")
                                    %default-substitute-urls))
                          (authorized-keys
                            (append (list (local-file "./key.pub"))
                                    %default-authorized-guix-keys)))))))

Предполагается, что файл key.pub содержит ключ подписи guix.example.org. После внесения этого изменения в файл конфигурации вашей операционной системы (например, /etc/config.scm) вы можете перенастроить и перезапустить службу guix-daemon или перезагрузиться, чтобы изменения вступили в силу:

$ sudo guix system reconfigure /etc/config.scm
$ sudo herd restart guix-daemon

Если вы используете Guix в качестве пакетного менеджера на другом дистрибутиве, вместо вышеописанного вы должны предпринять следующие шаги, чтобы получить заменители с дополнительных серверов:

  1. Отредактируйте файл конфигурации службы для guix-daemon; когда исользуете systemd, это обычно /etc/systemd/system/guix-daemon.service. Добавьте параметр --substitute-urls команды guix-daemon при вызове в командной строке и перечислите интересующие URL-адреса (see guix-daemon --substitute-urls):
    … --substitute-urls='https://guix.example.org https://ci.guix.gnu.org'
    
  2. Перезапустите демон. Пример для systemd:
    systemctl daemon-reload
    systemctl restart guix-daemon.service
    
  3. Авторизуйте ключ нового сервера (see Вызов guix archive):
    guix archive --authorize < key.pub
    

    Опять же, это предполагает key.pub, содержащий открытый ключ, который guix.example.org использует для подписи замененителей.

Теперь все готово! Замены предпочтительно брать из https://guix.example.org, используя ci.guix.gnu.org в качестве альтернативы. Конечно, вы можете указать столько серверов-заменителей, сколько захотите, но с оговоркой, что поиск замены может быть замедлен, если потребуется связаться со слишком большим количеством серверов.

Обратите внимание, что бывают также ситуации, когда можно добавить URL-адрес замещающего сервера без авторизации его ключа. See Аутентификация подстановок, чтобы понять этот тонкий момент.


Next: , Previous: , Up: Подстановки   [Contents][Index]

5.3.4 Аутентификация подстановок

Guix определяет и вызывает ошибку, если происходит попытка использовать поддельную подстановку. А также он игнорирует подстановки, которые не подписаны, или те, которые не подписаны ни одним ключом из списка ACL.

Но всё же есть одно исключение: если не авторизованный сервер предоставляет подстановки, которые являются идентичными бит-к-биту с теми, которые предоставляет авторизованный сервер, тогда неавторизованный сервер становится приемлемым для скачивания. Например, положим, мы выбрали два сервера подстановок такой опцией:

--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: , Previous: , Up: Подстановки   [Contents][Index]

5.3.5 Настройки proxy

Substitutes are downloaded over HTTP or HTTPS. The http_proxy and https_proxy environment variables can be set in the environment of guix-daemon and are honored for downloads of substitutes. Note that the value of those environment variables in the environment where guix build, guix package, and other client commands are run has absolutely no effect.


Next: , Previous: , Up: Подстановки   [Contents][Index]

5.3.6 Ошибки при подстановке

Даже когда подстановка для деривации доступна, иногда попытка подстановки завершается неудачно. Это может происходить по разным причинам: сервер подстановок может быть отключен, подстановка могла быть недавно удалена, связь может прерываться и т.д.

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.

Чтобы узнать,. сколько подстановок доступны в данный момент, можно попробовать запустить команду guix weather (see Запуск guix weather). Эта команда предоставляет статистику подстановок, предоставляемых сервером.


Previous: , Up: Подстановки   [Contents][Index]

5.3.7 Касательно проверенных бинарников

Сегодня индивидуальный контроль над работой за компьютером находится в заложниках у корпораций, организаций и групп, которые имеют достаточно силы и решимости разрушить инфраструктуру компьютерных сетей и внедрить уязвимости. Использование подстановок ci.guix.gnu.org может быть удобным, мы также стимулируем пользователей собирать их у себя или даже устанавливать собственные фермы сборки, чтобы уменьшить зависимость от ci.guix.gnu.org. Одним из способов помочь является публикация программного обеспечения, которое вы собираете, используя guix publish, тогда другие получат дополнительный сервер на выбор, чтобы скачивать подстановки (see Запуск guix publish).

Guix определяет цель максимизировать воспроизводимость сборок (see Особенности). В большинстве случаев независимые сборки заданного пакета или деривации должны давать результаты, идентичные до бита. То есть, благодаря ряду независимых сборок пакета мы можем улучшить чистоту наших систем. Команда guix challenge должна помочь пользователям оценить серверы подстановок, а разработчикам - помочь выявить недетерминистические сборки пакетов (see Запуск guix challenge). Подобным образом опция --check команды guix build даёт возможность пользователям проверить, яляются ли установленные ранее подстановки подлинными, выполнив их локальную сборку (see guix build --check).

Мы хотим, чтобы Guix в будущем поддерживал публикации и запросы бинарников от/для пользователей в формате равноправного обмена (peer-to-peer). Если вы желаете обсудить этот проект, присоединяйтесь к нам guix-devel@gnu.org.


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.4 Пакеты со множественным выходом

Часто пакеты, определённые в Guix, имеют один выход, это значит, что исходный пакет даёт только одну директорию на складе. При запуске guix package -i glibc это устанавливает результат по умолчанию; результат по умолчанию называется выходом, но его имя может пропускаться, как показано в этой команде. В этом частном случае результат по умолчанию для glibc содержит все файлы заголовков C, разделяемые библиотеки, статические библиотеки, документацию Info и другие поставляемые файлы.

Часто более приемлемым будет разделить различные типы файлов, поставляемых одним исходным пакетом, на отдельные выходы (результаты). Например, библиотека GLib C, используемая GTK+ и связанными с ним пакетами, устанавливает более 20Мб связанной документации в виде страниц HTML. Чтобы экономить место, пользователи, которым это не нужно, документацию можно выделить в отдельный выход, называемый doc. Чтобы установить основной выход GLib, который содерит всё, кроме документации, можно запустить:

guix install glib

Команда для установки её документации:

guix install glib:doc

Некоторые пакеты устанавливают программы с различными “отпечатками зависимостей”. Например, пакет WordNet устанавливает и инструменты командной строки, и графический интерфейс (GUI). Первое зависит только от библиотеки C, а последнее зависит от Tcl/Tk и библиотек X. В таком случае мы оставляем инструменты командной строки в качестве результата по умолчанию, в то время как GUI поставляется как отдельный выход. Это экономит место для пользователей, которым не нужен GUI. Команда guix size может помочь выявить такие ситуации (see Запуск guix size). guix graph также полезна (see Запуск guix graph).

Есть несколько таких пакетов со множественным выходом в дистрибутиве GNU. Другие традиционные имена выходов включают lib - для библиотек и иногда файлов заголовков, bin - для самих программ, debug - для отладочной информации (see Установка файлов отладки). Выходы пакетов представлены в третьей колонке вывода guix package --list-available (see Вызов guix package).


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.5 Вызов guix gc

Пакеты, которые установлены, но не используются, могут быть очищены как мусор (garbage-collected). Команда guix gc позволяет пользователям непосредственно запустить сборщик мусора и восстановить место в директории /gnu/store. Это единственный способ удалить файлы из /gnu/store — удаление файлов вручную может поломать её безвозвратно!

Сборщик мусора имеет набор известных корней (roots): любой файл в /gnu/store, доступный из корня, рассматривается как живой (live) и не может быть удалён; любой другой файл рассматривается как мёртвый (dead) и может быть удалён. Набор корней сборщика мусора (сокращённо "GC roots") содержит профили пользователей по умолчанию; по умолчанию символические ссылки в /var/guix/gcroots представляют эти корни сборщика мусора. Новые корни могут добавляться, например, командой guix build --root (see Запуск guix build). Команда guix gc --list-roots отображает их.

Перед запуском guix gc --collect-garbage для освобождения места часто бывает полезно удалить старые поколения из пользовательских профилей; так старые пакеты, относящиеся к этим поколениям, будут удалены. Это можно сделать, запустив guix package --delete-generations (see Вызов guix package).

Мы рекомендуем запускать сборщик мусора периодически, или когда вы хотите освободить место на диске. Например, чтобы гарантировать, что по меньшей мере 5 Гб будет доступно на вашем диске, просто запустите:

guix gc -F 5G

Хорошо бы запускать это как неинтерактивную периодическую задачу (see Запланированное исполнения задач, чтобы узнать, как добавить такую задачу). Запуск guix gc без аргументов соберёт столько мусора, сколько возможно, но это часто не удобно: можно обнаружить, что придётся заново собирать или скачивать программы, "убитые" сборщиком мусора, хотя они необходимы для сборки другого софта, например, это касается инструментов компилятора.

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]

Собрать мусор, то есть недоступные файлы в /gnu/store и поддиректориях. Это операция по умолчанию, если не заданы опции.

Если задана min, остановиться, когда min байт собрано. min может быть числом байт или может содержать единицу измерения в суффиксе, как например, MiB для мебибайт и GB гигабайт (see size specifications in GNU Coreutils).

Если min пропущено, собрать весь мусор.

--free-space=free
-F free

Собирать мусор, пока не станет доступно free места в /gnu/store, если возможно; free описывает дисковое пространство, как 500MiB, как это описанов выше.

Когда free или более места стало свободно в /gnu/store, ничего не делать и немедленно выйти.

--delete-generations[=duration]
-d [duration]

Перед запуском сборщика мусора удалить все поколения, старше duration, для всех пользовательских профилей; если запускать от root, это применяется для всех профилей всех пользователей.

Например, следующая команда удаляет все поколения всех ваших профилей, которые старше 2 месцев (кроме текущего поколения), а затем запускается процесс освобождения мместа, пока по меньшей мере 10 GiB не станет доступно:

guix gc -d 2m -F 10G
--delete
-D

Попытаться удалить все файлы и директории склада, приведённые в аргументах. Это завершается с ошибкой, если какие-либо файлы не присутствуют на складе, или если они ещё живы (live).

--list-failures

Вывести список элементов склада, которые относятся к кешированным неудачным сборкам.

Это ничего не выводит, если демон не был запущен с опцией --cache-failures (see --cache-failures).

--list-roots

Вывести список корней сборщика мусора (GC roots), которыми владеет пользователь; при запуске от root, выводит список всех корней сборщика мусора.

--list-busy

Составляет список элементов хранилица, исользуемых запущенными в данное время процессами. Эти элементы считаются корнями GC: они не могут быть удалены.

--clear-failures

Удалить заданные элементы склада из кеша неудачных сборок.

Опять же эта опция имеет смысл, если демон запущен с --cache-failures. В противном случае это не имеет эффекта.

--list-dead

Вывести список мёртвых файлов и директорий, которые по-прежнему присутствуют на складе, то есть файлы и директории, не доступные более из любого корня.

--list-live

Вывести список живых файлов и директорий склада.

В дополнение можно запросить связи между существующими файлами на складе:

--references
--referrers

Вывести список связанных (обязательно, ссылающихся) файлов на складе с указанными аргументами.

--requisites
-R

Вывести всё необходимое для файлов на складе, указанных в аргументах. Всё необходимое включает сами файлы на складе, их связи и связи их связей рекурсивно. Другими словами, выводимый список — это непосредственный конвейер файлов на складе.

См. See Запуск guix size для информации об инструменте профилирования конвейера для элемента. См. See Запуск guix graph для информации об инструменте визуализации графа связей.

--derivers

Вернуть деривацию(-ии), производящие данные элементы склада (see Деривации).

Например, эта команда:

guix gc --derivers $(guix package -I ^emacs$ | cut -f4)

возвращает файл(ы) .drv, которые произвели пакет emacs, установленный в вашем профиле.

Отметим, что может быть не найдено ни одного файла .drv, например, потому что эти файлы были удалены сборщиком мусора. Также может быть более одного файла .drv из-за дериваций с фиксированным выходом.

Наконец, следующие опции позволяют проверить целостность склада и контролировать использование диска.

--verify[=options]

Проверить целостность склада.

По умолчанию убедиться, что все элементы склада, которые в базе данных демона помечены как действующие, на самом деле присутствуют в /gnu/store.

Опции options, если они указаны, должны представлять собой список, разделённый запятыми, содержащий одно или более значений contents и repair.

Если задано --verify=contents, демон вычисляет хеш содержимого каждого элемента склада и сравнивает с его хешем в базе данных. Несовпадения хеша отображаются в отчёте как повреждение данных. Так как она проходит все файлы склада, эта команда может занять много времени, особенно в системах с медленным диском.

Использование --verify=repair или --verify=contents,repair указывает демону предпринять попытку восстановить разрушенные элементы склада, выбирая подстановки для них (see Подстановки). Так как восстановление не атомарное, и поэтому потенциально опасно, оно доступно только системному администратору. Малозатратная альтернатива в случае, если вы знаете точно, какие элементы склада испорчены, — это guix build --repair (see Запуск guix build).

--optimize

Оптимизировать склад с помощью жёстких ссылок на идентичные файлы — это дедупликация.

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: , Up: Управление пакетами   [Contents][Index]

5.6 Вызов 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. guix pull ensures that the code it downloads is authentic by verifying that commits are signed by Guix developers.

В частности, guix pull загружает код из channel (see Каналы), указанного одним из следующих способов, в следующем порядке:

  1. опция --channels;
  2. пользовательский файл ~/.config/guix/channels.scm;
  3. общесистемный файл /etc/guix/channels.scm file;
  4. встроенные по умолчанию каналы определены в переменной %default-channels.

После выполнения этой команды guix package будет использовать пакеты и те их версии, которые имеются в только что полученной копии Guix. Эта последняя версия будет источником также всех команд Guix, модулей Scheme. Из этого обновления станет доступен набор команд guix.

Any user can update their Guix copy using guix pull, and the effect is limited to the user who ran 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.

Результат запуска guix pull — это профиль profile, доступный в ~/.config/guix/current, содержащий последний Guix. Так что обязательно добавьте этот адрес первым в пути поиска, чтобы использовать последнюю версию, а также для руководства Info (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, для информации о других способах получить информацию о текущем статусе Guix.

This ~/.config/guix/current profile works exactly like the profiles 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 pull --roll-back
switched from generation 3 to 2
$ guix pull --delete-generations=1
deleting /var/guix/profiles/per-user/charlie/current-guix-1-link

Вы также можете использовать guix package (see Вызов guix package), чтобы управлять профилем, называя его явно:

$ 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

Команда guix pull обычно вызывается без аргументов, но поддерживает следующие опции:

--url=url
--commit=commit
--branch=branch

Скачать код канала guix из указанного url, относящийся к обозначенному коммиту commit (корректный ID коммита Git, представленный в виде шестнадцатеричной строки), или ветке branch.

Эти опции внедрены для удобства, но также можно задать конфигурационный файл ~/.config/guix/channels.scm или использовать опцию --channels (смотрите ниже).

--channels=file
-C file

Read the list of channels from file instead of ~/.config/guix/channels.scm or /etc/guix/channels.scm. file must contain Scheme code that evaluates to a list of channel objects. See Каналы, for more information.

--news
-N

Отображение списка пакетов, добавленных или обновленных со времени предыдущего поколения, а также, иногда, новостей, написанных авторами каналов для своих пользователей (see Writing Channel News).

The package information is the same 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]

Вывести список всех поколений ~/.config/guix/current или, если предоставлен паттерн pattern, подмножество поколений, которые соответствуют pattern. Синтаксис pattern — такой же, как у guix package --list-generations (see Вызов guix package).

--roll-back

Roll back to the previous generation of ~/.config/guix/current—i.e., undo the last transaction.

--switch-generation=pattern
-S pattern

Переключиться на определённое поколение, опрделённое 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.

--delete-generations[=pattern]
-d [pattern]

Если pattern пропущен, удалит все поголения, кроме текущего.

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.

Отметим, что удаление поколений делает невозможным откат к ним. Следовательно эта команда должна использоваться внимательно.

См. See Вызов guix describe, чтобы узнать, как вывести информацию только о текущем поколении.

--profile=profile
-p profile

Использовать профиль profile вместо ~/.config/guix/current.

--dry-run
-n

Показать, какие коммиты будут использоваться, и что будет собрано или скачано в виде подстановок, но не выполнять эту работу.

--allow-downgrades

Разрешить загружать более старые или несвязанные версии каналов, чем те, которые используются в настоящее время.

По умолчанию guix pull защищает от так называемых “атак на более раннюю версию”, когда репозиторий Git данного канала будет сброшен до более ранней или несвязанной версии, что может привести к установке более старых, известных уязвимых версий пакетов.

Примечание: Прежде чем использовать --allow-downgrades, убедитесь, что вы понимаете его последствия для безопасности.

--disable-authentication

Разрешить загрузку канала без его аутентификации.

По умолчанию guix pull аутентифицирует код, загруженный из каналов, проверяя, что его коммиты подписаны авторизованными разработчиками, и выдает ошибку, если это не так. Эта опция дает указание не выполнять такую проверку.

Примечание: Прежде чем использовать --disable-authentication, убедитесь, что вы понимаете его последствия для безопасности.

--system=system
-s system

Предпринять попытку собрать систему system, т.е. i686-linux, вместо типа системы хоста сборки.

--bootstrap

Использовать бутстрап Guile для сорки последнего Guix. Эта опция полезна только для разработчиков.

Механизм каналов channel позволяет указать guix pull, из какого репозитория или ветки скачивать, а также какие дополнительные репозитории должны использоваться для развёртки. См. See Каналы для подробной информации.

В добавок guix pull поддерживает все стандартные опции сборки (see Стандартные параметры сборки).


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.7 Запуск guix time-machine

Команда guix time-machine предоставляет доступ к другим версиям Guix, например, для установки более старых версий пакетов или для воспроизведения вычислений в идентичной среде. Версия используемого Guix определяется коммитом или файлом описания канала, созданным guix describe (see Вызов guix describe).

Основной синтаксис:

guix time-machine options… -- command arg

где command и arg… передаются без изменений в команду guix указанной ревизии. options, которые определяют эту ревизию, такие же, как и для guix pull (see Запуск guix pull):

--url=url
--commit=commit
--branch=branch

Use the guix channel from the specified url, at the given commit (a valid Git commit ID represented as a hexadecimal string), or branch.

--channels=file
-C file

Read the list of channels from file. file must contain Scheme code that evaluates to a list of channel objects. See Каналы for more information.

As for guix pull, the absence of any options means that the latest commit on the master branch will be used. The command

guix time-machine -- build hello

таким образом, мы соберем пакет hello, как определено в основной ветке, которая, как правило, является более новой версией Guix, чем вы установили. Путешествие во времени работает в обоих направлениях!

Note that guix time-machine can trigger builds of channels and their dependencies, and these are controlled by the standard build options (see Стандартные параметры сборки).


Next: , Previous: , Up: Управление пакетами   [Contents][Index]

5.8 Младшие версии

Примечание: Функциональность, описанная здесь, — это обзор технологии версии 1.3.0. Интерфейс может меняться.

Иногда вам может понадобиться перемешивать пакеты из ревизии Guix, которая работает в настоящий момент, с пакетами, доступными в другой ревизии Guix. Основания Guix inferiors позволяют вам получить это, составляя различные ревизии Guix произвольным образом.

Технически работа с ранними версиями — это в целом отдельный процесс Guix, связанный с главным процессом Guix через REPL (see Запуск guix repl). Модуль (guix inferior) позволяет запускать ранние версии и взаимодействовать с ними. Он также предоставляет высокоуровневый интерфейс для обзора и управления пакетами, которые поставляет ранняя версия — ранние версии пакетов.

При сочетании с каналами (see Каналы) ранние версии преоставляют простой способ взаимодействовать с отдельными ревизиями Guix. Например, предположим, вы хотите установить в ваш профиль текущий пакет guile вместе с тем guile-json, который был определён в предыдущей ревизии Guix (может быть, потому что новый guile-json имеет несовместимый API, и вы хотите запустить ваш код со старым API). Чтобы это сделать, можно написать манифест для использования с guix package --manifest (see Вызов guix package). В этом манифесте вы создадите описание ранней версии той предыдущей ревизии Guix, которая вас интересует, в которой вы ищете пакет guile-json ранней версии:

(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")))

Далее запуск guix package --manifest может вызвать сборку канала, который вы обозначили ранее, и в результате это задействует раннюю версию. Последовательные запуски будут быстрее, потому что ревизия Guix будет кеширована.

Модуль (guix inferior) предоставляет следующие процедуры для работы с ранними версиями:

Процедура Scheme: inferior-for-channels channels [#:cache-directory] [#:ttl] Возвращает раннюю версию для списка каналов

channels. Использует кеш в cache-directory, где компоненты могут восстанавливаться через ttl секунд. Эта процедура открывает новое соединение с демоном сборки.

Как побочный эффект, эта процедура может собирать или скачивать подстановки бинарников для channels, что может занять время.

Процедура Scheme: open-inferior directory [#:command "bin/guix"] Открывает раннюю версию Guix в directory,

запустив repl directory/command или эквивалент. Возвращает #f, если ранняя версия не может быть запущена.

Процедуры, приведённые ниже, обеспечивают работу и управление ранними версиями пакетов.

Процедура Scheme: inferior-packages inferior

Возвращает список пакетов, относящихся к ранней версии inferior.

Процедура Scheme: lookup-inferior-packages inferior name [version] Возвращает сортированный список пакетов ранней версии

inferior, содержащих имя name, поздняя версия - вначале. Если версия version задана, возвращает только пакеты с номером версии, начинающейся с version.

Процедура Scheme: inferior-package? obj

Возвращает true, если объект obj — это пакет ранней версии.

Процедура Scheme: inferior-package-name package
Процедура Scheme: inferior-package-version package
Процедура Scheme: inferior-package-synopsis package
Процедура Scheme: inferior-package-description package
Процедура Scheme: inferior-package-home-page package
Процедура Scheme: inferior-package-location package
Процедура Scheme: inferior-package-inputs package
Процедура Scheme: inferior-package-native-inputs package
Процедура Scheme: inferior-package-propagated-inputs package
Процедура Scheme: inferior-package-transitive-propagated-inputs package
Процедура Scheme: inferior-package-native-search-paths package
Процедура Scheme: inferior-package-transitive-native-search-paths package
Процедура Scheme: inferior-package-search-paths package

Эти процедуры являются двойниками метода доступа к записям пакетов (see ссылка на пакет). Большинство из них работают с запросами для ранней версии, из которой происходит package, так что ранняя версия должна оставаться живой, когда вы вызываете эти процедуры.

Inferior packages can be used transparently like any other package or file-like object in G-expressions (see G-Expressions). They are also transparently handled by the packages->manifest procedure, which is commonly used 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: , Previous: , Up: Управление пакетами   [Contents][Index]

5.9 Вызов guix describe

Часто может возникать вопрос: "Какую ревизию Guix я использую?" - Или: "Какие каналы я использую?" Это полезна информация во многих ситуациях: если вы хотите повторить окружение на другой машине или в другом пользовательском аккаунте, если вы хотите составить отчёт об ошибке, чтобы определить, какие изменения в канале, который вы используете, вызвали ошибку, или если вы хотите записать состояние вашей системы в целях воспроизводимости. Команда guix describe отвечает на эти вопросы.

В случае запуска после guix pull команда guix describe отображает канал(ы), из которых производилась сборка, включая URL и репозиториев и ID коммитов (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

Если вы знакомы с системой контроля версиями Git, эта команда по сути похожа на git describe; выход тот же, что в guix pull --list-generations, но ограничен текущим поколением (see the --list-generations option). Так как ID коммита Git выше ссылается однозначно на снимок Guix, эта информация — всё, что нужно для описания используемой ревизии Guix и повторения её.

Чтобы проще повторить Guix, guix describe также может вызываться для вывода списка каналов вместо читаемого описания выше:

$ guix describe -f channels
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (commit
          "e0fa68c7718fffd33d81af415279d6ddb518f727")))
        (introduction
           (make-channel-introduction
             "9edb3f66fd807b096b48283debdcddccfea34bad"
             (openpgp-fingerprint
               "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

Можно сохранить это в файл и подать на вход guix pull -C на любой другой машине или через время, чтобы инициализировать эту конкретную ревизию Guix (see the -C option). Теперь, когда можно развернуть подобную ревизию Guix, вы можете также полностью повторить программное окружение. Мы скромно полагаем, это чудесно. Надеемся, вам это тоже понравится!

Подробнее об опциях, поддерживаемых guix describe:

--format=format
-f format

Произвести вывод в указанном формате format, одном из:

human

произвести вывод для чтения человеком;

каналы

произвести список спецификаций каналов, который может использоваться в guix pull -C или вставлен в файл ~/.config/guix/channels.scm (see Запуск guix pull);

channels-sans-intro

как channels, но без поля Introduction; используйте его для создания спецификации канала, подходящей для Guix версии 1.1.0 или более ранней. Поле Introduction связано с аутентификацией канала (see Channel Authentication) и не поддерживается этими более ранними версиями;

json

произвести список спецификаций каналов в формате JSON;

recutils

произвести список спецификаций каналов в формате Recutils.

--list-formats

Вывести доступные форматы для --format опции.

--profile=profile
-p profile

Вывести информацию о профиле profile.


Previous: , Up: Управление пакетами   [Contents][Index]

5.10 Вызов guix archive

Команда guix archive даёт возможность пользователям экспортировать файлы со склада в простой архив и затем импортировать их на машину с работающим Guix. В частности, это позволяет передавать файлы склада одной машины на склад другой машины.

Примечание: Если вы ищете способ производить архивы в формате, который подходит для инструментов, отличных от Guix, смотрите see Запуск guix pack.

Чтобы экспортировать файлы склада в архив в стандартный вывод, выполните:

guix archive --export options specifications...

Спецификации specifications могут быть либо именами файлов или пакетами, как для команде guix package (see Вызов guix package). Например, следующая команда создаёт архив, содержащий выход gui пакета git и главный выход emacs:

guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar

Если указанные пакеты ещё не собраны, guix archive автоматически соберёт их. Процесс сборки может контролироваться обычными опциями сборки (see Стандартные параметры сборки).

Чтобы передать пакет emacs на машину, соединённую по SSH, нужно следующее:

guix archive --export -r emacs | ssh the-machine guix archive --import

Точно также для передачи всего профиля пользователя из одной машины на другую, выполните:

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh the-machine guix archive --import

However, note that, in both examples, all of emacs and the profile as well as all of their dependencies are transferred (due to -r), regardless of what is already available in the store on the target machine. The --missing option can help figure out which items are missing from the target store. The guix copy command simplifies and optimizes this whole process, so this is probably what you should use in this case (see Запуск guix copy).

Каждый элемент храниища написан в normalized archive или nar формате (описано ниже), и вывод guix archive --export (и ввод guix archive --import) есть nar bundle.

Формат nar по духу сравним с tar, но с отличиями, которые делают его более подходящим для наших целей. Во-первых, вместо записи всех метаданных Unix для каждого файла, в формате nar упоминается только тип файла (обычный, каталог или символическая ссылка); Разрешения Unix и владелец/группа отклонены. Во-вторых, порядок, в котором хранятся записи каталога, всегда следует порядку имен файлов в соответствии с порядком сопоставления C локали. Это делает создание архивов полностью детерминированным.

Формат пакета nar - это, по сути, конкатенация нуля или более nars вместе с метаданными для каждого элемента store, который содержит: имя файла, ссылки, соответствующую derivation и цифровую подпись.

При экспортировании демон подписывает цифровой подписью содержимое архива, и эта цифровая подпись прикрепляется. При импорте демон проверяет подпись и отменяет импорт в случае недействительной подписи, или если ключ подписи не авторизован.

Основные опции:

--export

Экспортировать указанные файлы хранилища или пакеты (смотрите ниже). Писать результирующий архив в стандартный вывод.

Зависимости не включаются в выход, если не задана опция --recursive.

-r
--recursive

When combined with --export, this instructs guix archive to include dependencies of the given items in the archive. Thus, the resulting archive is self-contained: it contains the closure of the exported store items.

--import

Read an archive from the standard input, and import the files listed therein into the store. Abort if the archive has an invalid digital signature, or if it is signed by a public key not among the authorized keys (see --authorize below).

--missing

Читать список имён файлов склада из стандартного ввода, одна линия - один файл, и писать в стандартный вывод подмножество этих файлов, отсутствующих на складе.

--generate-key[=parameters]

Generate a new key pair for the daemon. This is a prerequisite before archives can be exported with --export. This operation is usually instantaneous but it can take time if the system’s entropy pool needs to be refilled. On Guix System, guix-service-type takes care of generating this key pair the first boot.

The generated key pair is typically stored under /etc/guix, in signing-key.pub (public key) and signing-key.sec (private key, which must be kept secret). When parameters is omitted, an ECDSA key using the Ed25519 curve is generated, or, for Libgcrypt versions before 1.6.0, it is a 4096-bit RSA key. Alternatively, parameters can specify genkey parameters suitable for Libgcrypt (see gcry_pk_genkey in The Libgcrypt Reference Manual).

--authorize

Авторизовать импорт, подписанный публичным ключом, поступивший на стандартный ввод. Публичный ключ должен быть в формате s-expression, то есть в таком же формате, как файл signing-key.pub.

The list of authorized keys is kept in the human-editable file /etc/guix/acl. The file contains “advanced-format s-expressions” and is structured as an access-control list in the Simple Public-Key Infrastructure (SPKI).

--extract=directory
-x directory

Читать архив, представляющий один элемент, в качестве поставленного серверами подстановки (see Подстановки) и извлечь его в директорию directory. Это низкоуровневая операция, необходимая только в очень редких случаях, смотрите ниже.

Например, следующая команда распаковывает подстановку Emacs, поставленную ci.guix.gnu.org в /tmp/emacs:

$ wget -O - \
  https://ci.guix.gnu.org/nar/gzip/…-emacs-24.5 \
  | gunzip | guix archive -x /tmp/emacs

Архивы, представляющие один элемент, отличаются от архивов, содержащих множество элементов, производимых guix archive --export. Они содержат один элемент склада, но они не включают подпись. Так что эта операция не использует верификацию, и его выход должен рассматриваться как небезопасный.

The primary purpose of this operation is to facilitate inspection of archive contents coming from possibly untrusted substitute servers (see Запуск guix challenge).

--list
-t

Читать архив, представляющий один элемент, в качестве поставленного серверами подстановки (see Подстановки) и распечатайте список файлов, которые он содержит, как в этом примере:

$ wget -O - \
  https://ci.guix.gnu.org/nar/lzip/…-emacs-26.3 \
  | lzip -d | guix archive -t

Next: , Previous: , Up: Top   [Contents][Index]

6 Каналы

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. Guix is able to take into account security concerns and deal with authenticated updates.


Next: , Up: Каналы   [Contents][Index]

6.1 Указание дополнительных каналов

You can specify additional channels to pull from. 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 variant packages to those Guix provides.
(cons (channel
        (name 'variant-packages)
        (url "https://example.org/variant-packages.git"))
      %default-channels)

Заметим, что сниппет выше (всегда!) код Scheme; мы используем cons для добавления канала в список каналов, то есть в переменную %default-channels (see cons and lists in GNU Guile Reference Manual). Если этот файл написан, guix pull производит сборку не только Guix, но и пакетных модулей из вашего репозитория. В результате в ~/.config/guix/current содержится объединение Guix и ваших собственных пакетных модулей:

$ 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
  variant-packages dd3df5e
    repository URL: https://example.org/variant-packages.git
    branch: master
    commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
  11 new packages: variant-gimp, variant-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 variant-personal-packages channel. Among the new and upgraded packages that are listed, some like variant-gimp and variant-emacs-with-cool-features might come from variant-packages, while others come from the Guix default channel.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.2 Использование отдельного канала Guix

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 another 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 another repo.
(list (channel
        (name 'guix)
        (url "https://example.org/another-guix.git")
        (branch "super-hacks")))

From there on, guix pull will fetch code from the super-hacks branch of the repository at example.org. The authentication concern is addressed below ((see Аутентификация канала).


Next: , Previous: , Up: Каналы   [Contents][Index]

6.3 Копирование Guix

Результат guix pull --list-generations выше показывает точно, какие коммиты были использованы для сборки данной инстанции Guix. Так что мы можем повторить её, скажем, на другой машине, предоставив объявление канала в ~/.config/guix/channels.scm, которое завязано на этих коммитах:

;; Deploy specific commits of my channels of interest.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "6298c3ffd9654d3231a6f25390b056483e8f407c"))
      (channel
       (name 'variant-packages)
       (url "https://example.org/variant-packages.git")
       (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

The guix describe --format=channels command can even generate this list of channels directly (see Вызов guix describe). The resulting file can be used with the -C options of guix pull (see Запуск guix pull) or guix time-machine (see Вызов guix time-machine).

И тогда две машины будут работать с полностью одинаковым Guix, имея доступ к абсолютно одинаковым пакетам. Результат guix build gimp на одной машине будет совершенно таким же, бит к биту, как результат этой команды на другой машине. Это также означает, что обе машины имеют доступ ко всем исходным кодам Guix, следовательно, ко всем исходным кодам каждого пакета, определённого в Guix.

Это даёт вам супервозможности, позволяя вам отслеживать и управлять происхождением артефактов бинарников с точной детализацией, также повторять программные окружения — это воспроизводимость высокого уровня. Смотрите See Младшие версии, чтобы узнать другие преимущества таких супервозможностей.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.4 Аутентификация канала

guix pull и guix time-machine аутентифицируют код, полученный из каналов: они гарантируют, что каждый полученный коммит подписан авторизованным разработчиком. Цель состоит в том, чтобы защитить канал от несанкционированных изменений, которые могут привести к запуску вредоносного кода пользователями.

Как пользователь, вы должны предоставить channel introduction в вашем файле канала, чтобы Guix знал как авторизовать свой первый коммит. Спецификация канала, включая введения, выглядит как-то так:

(channel
  (name 'some-channel)
  (url "https://example.org/some-channel.git")
  (introduction
   (make-channel-introduction
    "6f0d8cc0d88abb59c324b2990bfee2876016bb86"
    (openpgp-fingerprint
     "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))

В приведенной выше спецификации указано имя и URL-адрес канала. Вызов make-channel-introduction выше указывает, что аутентификация этого канала начинается с коммита 6f0d8cc…, который подписывается ключом OpenPGP с отпечатком CABB A931….

Для основного канала, называемого guix, вы автоматически получаете эту информацию из вашей установки Guix. Для других каналов, укажите introduction для канала, предоставленное авторами канала, в ваш файл channels.scm. Убедитесь, что вы получили introduction канала из надежного источника, так как это основа вашего доверия.

Если вам любопытены механизмы авторизации, читайте дальше!


Next: , Previous: , Up: Каналы   [Contents][Index]

6.5 Каналы с заменителями

When running guix pull, Guix will first compile the definitions of every available package. This is an expensive operation for which substitutes (see Подстановки) may be available. The following snippet in channels.scm will ensure that guix pull uses the latest commit with available substitutes for the package definitions: this is done by querying the continuous integration server at https://ci.guix.gnu.org.

(use-modules (guix ci))

(list (channel-with-substitutes-available
       %default-guix-channel
       "https://ci.guix.gnu.org"))

Note that this does not mean that all the packages that you will install after running guix pull will have available substitutes. It only ensures that guix pull will not try to compile package definitions. This is particularly useful when using machines with limited resources.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.6 Создание канала

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?

Внимание: Прежде чем вы крикнете Ух-ты, это круто! и опубликуете собственный канал, необходимо учесть некоторые предостережения:

Вы предупреждены! Обозначив это, мы верим, что внешние каналы — это способ для вас проявлять свою свободу и вместе с тем расширять коллекцию пакетов Guix и делиться улучшениями, что является основными догматами свободного программного обеспечения. Пожалуйста, свяжитесь с нами по e-mail guix-devel@gnu.org, если вы хотите обсудить это.

Чтобы создать канал, создайте репозиторий Git, содержащий ваши собственные пакетные модули, и сделайте его доступным. Репозиторий может содержать что-либо, но полезный канал будет содержать модули Guile, экспортирующие пакеты. Когда вы начали использовать канал, Guix будет работать, как будто корневая директория репозитория Git этого канала добавлена в путь загрузки Guile (see Load Paths in GNU Guile Reference Manual). Например, если ваш канал содержит файл my-packages/my-tools.scm, который определяет модуль Guile, тогда модуль будет доступен под именем (my-packages my-tools), и вы сможете использовать его, как любой другой модуль (see Модули in GNU Guile Reference Manual).

Как автор канала, рассмотрите возможность объединения материалов для аутентификации с вашим каналом, чтобы пользователи могли его аутентифицировать. See Аутентификация канала и Указание авторизаций канала для получения информации о том, как это сделать.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.7 Пакетные модули в поддиректории

Как автор канала, вы можете хранить модули канала в подкаталоге. Если ваши модули находятся в подкаталоге guix, вы должны добавить файл метаданных .guix-channel, который содержит:

(channel
  (version 0)
  (directory "guix"))

Next: , Previous: , Up: Каналы   [Contents][Index]

6.8 Объявление зависимостей канала

Авторы канала могут решить расширить коллекцию пакетов пакетами, которые поставляются другими каналами. Они могут объявить, что их канал зависит от других каналов, в файле метаданных .guix-channel, который нужно разместить в корне репозитория канала.

Файл метаданных должен содержать простое выражение S-expression как это:

(channel
 (version 0)
 (dependencies
  (channel
   (name some-collection)
   (url "https://example.org/first-collection.git")

   ;; The 'introduction' bit below is optional: you would
   ;; provide it for dependencies that can be authenticated.
   (introduction
    (channel-introduction
      (version 0)
      (commit "a8883b58dc82e167c96506cf05095f37c2c2c6cd")
      (signer "CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"))))
  (channel
   (name some-other-collection)
   (url "https://example.org/second-collection.git")
   (branch "testing"))))

В примере выше объявлен канал, который зависит от двух других каналов, из которых оба будут скачаны автоматически. Модули, предоставляемые каналом, будут скомпилированы в окружении, в котором доступны модули всех этих каналов.

В целях воспроизводимости и сопровождения вы должны избегать зависимостей от каналов, которые вы не контролируете, и вы должны стремиться минимизировать число зависимостей.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.9 Указание авторизаций канала

Как мы видели выше, Guix гарантирует, что исходный код, который он получает из каналов, поступает от авторизованных разработчиков. Как автор канала, вам необходимо указать список авторизованных разработчиков в файле .guix-authorizations в репозитории Git канала. Правило аутентификации простое: каждый коммит должен быть подписан ключом, указанным в файле .guix-authorizations его родительского коммита(ов) 10 файл .guix-authorizations выглядит так:

;; Пример '.guix-authorizations' файла.

(authorizations
 (version 0)               ;current file format version

 (("AD17 A21E F8AE D8F1 CC02  DBD9 F8AE D8F1 765C 61E3"
   (name "alice"))
  ("2A39 3FFF 68F4 EF7A 3D29  12AF 68F4 EF7A 22FB B2D5"
   (name "bob"))
  ("CABB A931 C0FF EEC6 900D  0CFB 090B 1199 3D9A EBB5"
   (name "charlie"))))

За каждым отпечатком следуют необязательные пары ключ/значение, как в примере выше. В настоящее время эти пары ключ/значение игнорируются.

Это правило аутентификации создает проблему с курицей и яйцом: как мы аутентифицируем первый коммит? В связи с этим: как нам поступать с каналами, история репозитория которых содержит неподписанные коммиты и не имеет .guix-authorizations? И как нам разветвлять существующие каналы?

Channel introductory отвечает на данные вопросы, описывая первый коммит канала, который должен быть аутентифицирован. При первом вызове канала с помощью guix pull или guix time-machine команда ищет introductory коммит и проверяет, что он подписан указанным ключом OpenPGP. С этого момента он аутентифицирует коммиты в соответствии с приведенным выше правилом.

Кроме того, ваш канал должен предоставлять все ключи OpenPGP, которые когда-либо упоминались в .guix-authorizations, хранящиеся как файлы .key, которые могут быть либо двоичными, либо “ASCII-armored”. По умолчанию эти файлы .key ищутся в ветке с именем keyring, но вы можете указать другое имя ветки в .guix-channel следующим образом:

(channel
  (version 0)
  (keyring-reference "my-keyring-branch"))

Подытоживая, как автор канала, вы должны сделать три вещи, чтобы позволить другим пользователям авторизовать ваш код:

  1. Экспортируйте ключи OpenPGP прошлых и нынешних коммиттеров с помощью gpg --export и сохраните их в файлах .key, по умолчанию в ветке с именем keyring (мы рекомендуем сделать это в orphan branch).
  2. Добавьте .guix-authorizations в репозиторий канала. Сделайте это в подписанном коммите (see Доступ к коммитам, чтобы узнать, как подписывать коммиты Git)
  3. Рекламируйте channel introduction, например, на веб-странице вашего канала. Channel introduction, как мы видели выше, - это пара коммит/ключ, то есть коммит, который представляет .guix-authorizations, и отпечаток OpenPGP, использованный для его подписи.

Перед отправкой в ваш общедоступный репозиторий Git вы можете запустить guix git-authenticate, чтобы убедиться, что вы подписали все коммиты, которые собираетесь отправить, авторизованным ключом:

guix git authenticate commit signer

где commit и signer являются вашим channel introduction. See Запуск guix git authenticate, подробнее.

Публикация подписанного канала требует дисциплины: любая ошибка, такая как неподписанная фиксация или фиксация, подписанная неавторизованным ключом, не позволит пользователям pull’ить с вашего канала - в этом весь смысл аутентификации! Обратите внимание на merge, в частности: merge коммиты считаются аутентичными, если и только если они подписаны ключом, присутствующим в файле .guix-authorizations обоих веток.


Next: , Previous: , Up: Каналы   [Contents][Index]

6.10 Основной URL

Авторы каналов могут указать основной URL-адрес репозитория Git своего канала в файле .guix-channel, например:

(channel
  (version 0)
  (url "https://example.org/guix.git"))

This allows guix pull to determine whether it is pulling code from a mirror of the channel; when that is the case, it warns the user that the mirror might be stale and displays the primary URL. That way, users cannot be tricked into fetching code from a stale mirror that does not receive security updates.

Эта функция имеет смысл только для аутентифицированных репозиториев, таких как официальный канал guix, для которого guix pull гарантирует, что полученный код аутентичен.


Previous: , Up: Каналы   [Contents][Index]

6.11 Написание новостей канала

Авторы канала могут захотеть сообщить своим пользователям информацию о важных изменениях в канале. Вы можете отправить им письмо по электронной почте, но это не удобно.

Вместо этого каналы могут предоставлять файл новостей; когда пользователи канала запускают guix pull, этот файл новостей автоматически читается, и guix pull --news может отображать объявления, которые соответствуют новым зафиксированным коммитам, если таковые имеются.

Для этого авторы каналов должны сначала объявить имя файла новостей в своем файле .guix-channel:

(channel
  (version 0)
  (news-file "etc/news.txt"))

Сам файл новостей, etc/news.txt в этом примере, должен выглядеть примерно так:

(channel-news
  (version 0)
  (entry (tag "the-bug-fix")
         (title (en "Fixed terrible bug")
                (fr "Oh la la"))
         (body (en "@emph{Good news}!  It's fixed!")
               (eo "Certe ĝi pli bone funkcias nun!")))
  (entry (commit "bdcabe815cd28144a2d2b4bc3c5057b051fa9906")
         (title (en "Added a great package")
                (ca "Què vol dir guix?"))
         (body (en "Don't miss the @code{hello} package!"))))

В то время как файл новостей использует синтаксис Scheme, избегайте называть его расширением .scm, иначе он будет выбран при построении канала и выдаст ошибку, поскольку это недопустимый модуль. Кроме того, вы можете переместить модуль канала в подкаталог и сохранить файл новостей в другом каталоге.

Файл состоит из списка news entries. Каждая запись связана с коммитом или тегом: она описывает изменения, сделанные в этом коммите, возможно, также и в предыдущих коммитах. Пользователи видят записи только при первом получении коммита, на который ссылается запись.

Поле title должно быть однострочным, а body может быть произвольно длинным, и оба могут содержать Texinfo разметку (see Overview in GNU Texinfo). И заголовок, и тело являются списком языковых тегов/кортежей сообщений, что позволяет комманде guix pull отображать новости на языке, соответствующем языку пользователя.

Если вы хотите перевести новости, используя рабочий процесс на основе gettext, вы можете извлечь переводимые строки с помощью xgettext (see xgettext Invocation in GNU Gettext Utilities). Например, если вы сначала пишете новости на английском языке, команда ниже создает PO-файл, содержащий строки для перевода:

xgettext -o news.po -l scheme -ken etc/news.txt

Подводя итог, да, вы можете использовать свой канал в качестве блога. Но будьте осторожны, это не совсем то, что могут ожидать ваши пользователи.


Next: , Previous: , Up: Top   [Contents][Index]

7 Разработка

Если вы являетесь разработчиком программного обеспечения, Guix предоставляет инструменты, которые вы можете найти полезными, независимо от языка разработки. Об этом данный раздел.

Команда guix environment предоставляет удобный способ установить окружение разработки на ваш выбор, содержащее все зависимости и инструменты, необходимые для работы с пакетом программы. Команда guix pack позволяет создавать наборы приложений, которые могут легко распространяться для пользователей, которые не используют Guix.


Next: , Up: Разработка   [Contents][Index]

7.1 Вызов guix environment

Цель guix environment — помощь программистам в создании окружения разработки, которое можно повторять, без влияния на профили пакетов. Инструмент guix environment принимает один или более пакетов, собирает все входные данные для них и создаёт окружение оболочки для их использования.

Основной синтаксис:

guix environment options package

Следующий пример порождает новую оболочку, установленную для разработки GNU Guile:

guix environment guile

Если необходимые зависимости еще не собраны, guix environment автоматически построит их. Среда новой оболочки - это расширенная версия среды, в которой была запущена guix environment. Она содержит необходимые пути поиска для сборки данного пакета, добавленные к существующим переменным среды. Чтобы создать “чистую” среду, в которой исходные переменные среды не были установлены, используйте параметр --pure 11.

Exiting from a Guix environment is the same as exiting from the shell, and will place the user back in the old environment before guix environment was invoked. The next garbage collection (see Вызов guix gc) will clean up packages that were installed from within the environment and are no longer used outside of it.

guix environment defines the GUIX_ENVIRONMENT variable in the shell it spawns; its value is the file name of the profile of this environment. This allows users to, say, define a specific prompt for development environments in their .bashrc (see Bash Startup Files in The GNU Bash Reference Manual):

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

... или просмотеть профиль:

$ ls "$GUIX_ENVIRONMENT/bin"

Дополним, что может быть указано более одного пакета, в таком случае используется объединённые входные данные для указанных пакетов. Например, команда ниже порождает оболочку, в котором доступны все зависимости, как Guile, так и Emacs:

guix environment guile emacs

Иногда интерактивная сессия оболочки не нужна. Можно вызвать произвольную команду при указании токена --, который отделяет команду от остальных аргументов:

guix environment guile -- make -j4

В других ситуациях удобнее указать список паетов, необходимых для окружения. Например, следующая команда запускает python из окружения, содержащего Python 2.7 и NumPy:

guix environment --ad-hoc python2-numpy python-2.7 -- python

Furthermore, one might want the dependencies of a package and also some additional packages that are not build-time or runtime dependencies, but are useful when developing nonetheless. Because of this, the --ad-hoc flag is positional. Packages appearing before --ad-hoc are interpreted as packages whose dependencies will be added to the environment. Packages appearing after are interpreted as packages that will be added to the environment directly. For example, the following command creates a Guix development environment that additionally includes Git and strace:

guix environment --pure guix --ad-hoc git strace

Иногда возникает необходимость изолировать окружение настолько, насколькоо возможно, для максимальной чистоты и воспроизводимости. В частности, при использовании Guix на дистрибутиве, отличном от системы Guix, желательно предотвращать доступ из окружения разработки к /usr/bin и другим ресурсам системы. Например, следующая команда порождает Guile REPL в "контейнере", в котором монтированы только склад и текущая рабочая директория:

guix environment --ad-hoc --container guile -- guile

Примечание: The --container option requires Linux-libre 3.19 or newer.

Another typical use case for containers is to run security-sensitive applications such as a web browser. To run Eolie, we must expose and share some files and directories; we include nss-certs and expose /etc/ssl/certs/ for HTTPS authentication; finally we preserve the DISPLAY environment variable since containerized graphical applications won’t display without it.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

Доступные опции резюмированы ниже.

--root=file
-r file

Создать символическую ссылку file на профиль этого окружения и зарегистрировать её как корень сборщика мусора.

Это полезно, если вы хотите защитить своё окружение от сборщика мусора, сделать его "постоянным".

Если эта опция пропущена, окружеие защищено от сборщика мусора только на время сессии guix environment. Это означает, что в следующий раз, когда вы создадите такое же окружение, вам потребуется пересобирать и скачивать пакеты заново. See Вызов guix gc, for more on GC roots.

--expression=expr
-e expr

Создать окружение для пакета или списка пакетов, которые соответствуют выражению expr.

Например, запуск:

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

запускает оболочку с окружением для этого специфического варианта пакета PETSc.

Запуск:

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

стартует оболочку со всеми доступными базовыми пакетами.

Команды выше используют только выход по умолчанию обозначенных пакетов. Чтобы выбрать другие выходы, можно указать два элемента кортежей:

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'
--load=file
-l file

Создать окружение для пакета или списка пакетов, код которых задан в файле file.

Например, file может содержать определение (see Описание пакетов):

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package (inherit gdb)
  (native-inputs `(("autoconf" ,autoconf-2.64)
                   ("automake" ,automake)
                   ("texinfo" ,texinfo)
                   ,@(package-native-inputs gdb))))
--manifest=file
-m file

Create an environment for the packages contained in the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

Это то же, что опция с таким же именем в guix package (see --manifest) и использует такие же файлы манифестов.

--ad-hoc

Включить все указанные пакеты в результирующее окружение, если бы целевой (лат. ad hoc) пакет имел бы их как входные данные. Эта опция полезна для быстрого создания окружения без необходимости писать выражение типа пакет, содержащее желаемые входные данные.

Например, команда:

guix environment --ad-hoc guile guile-sdl -- guile

запускает guile в окружении, в котором доступны Guile и Guile-SDL.

Отметим, что этот пример явно запрашивает выходы guile и guile-sdl по умолчанию, но возможно запросить специфичный выход, то есть glib:bin запрашивает выход bin из glib (see Пакеты со множественным выходом).

This option may be composed with the default behavior of guix environment. Packages appearing before --ad-hoc are interpreted as packages whose dependencies will be added to the environment, the default behavior. Packages appearing after are interpreted as packages that will be added to the environment directly.

--pure

Unset existing environment variables when building the new environment, except those specified with --preserve (see below). This has the effect of creating an environment in which search paths only contain package inputs.

--preserve=regexp
-E regexp

При использовании вместе с --pure, оставить содержимое переменных окружения, соответствующих выражению regexp — другими словами, включить их в "белый список" переменных окружения, которые не должны обнуляться. Эту опцию можно повторять несколько раз.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

Этот пример запускает mpirun в контексте, в котором определены только следующие переменные окружения: PATH, переменные окружения, чьи имена начинаются с ‘SLURM’, а также обычные "дорогие" переменные (HOME, USER, и т.д.).

--search-paths

Отобразить определения переменных окружения, которые составляют окружение.

--system=system
-s system

Попытаться собрать систему system, то есть i686-linux.

--container
-C

Run command within an isolated container. The current working directory outside the container is mapped inside the container. Additionally, unless overridden with --user, a dummy home directory is created that matches the current user’s home directory, and /etc/passwd is configured accordingly.

The spawned process runs as the current user outside the container. Inside the container, it has the same UID and GID as the current user, unless --user is passed (see below).

--network
-N

Разделять пространство сетевых имён контейнера с хостящей системой. Контейнеры, созданные без этого флага, могут только иметь доступ к петлевому устройству.

--link-profile
-P

For containers, link the environment profile to ~/.guix-profile within the container and set GUIX_ENVIRONMENT to that. This is equivalent to making ~/.guix-profile a symlink to the actual profile within the container. Linking will fail and abort the environment if the directory already exists, which will certainly be the case if guix environment was invoked in the user’s home directory.

Certain packages are configured to look in ~/.guix-profile for configuration files and data;12 --link-profile allows these programs to behave as expected within the environment.

--user=user
-u user

Использовать в контейнере имя пользователя user вместо текущего пользователя. Созданная внутри контейнера запись /etc/passwd будет содержать имя user, домашняя директория будет /home/user, но не будут копированы пользовательские данные GECOS. Более того, внутри контейнера UID и GID будут 1000. user не обязательно должен существовать в системе.

Additionally, any shared or exposed path (see --share and --expose respectively) whose target is within the current user’s home directory will be remapped relative to /home/USER; this includes the automatic mapping of the current working directory.

# will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
cd $HOME/wd
guix environment --container --user=foo \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Это ограничит утечку данных идентификации пользователя через домашние пути и каждое из полей пользователя. Это один единственный компонент расширенного решения приватности/анонимности — ничто не войдёт, ничто не выйдет.

--no-cwd

For containers, the default behavior is to share the current working directory with the isolated container and immediately change to that directory within the container. If this is undesirable, --no-cwd will cause the current working directory to not be automatically shared and will change to the user’s home directory within the container instead. See also --user.

--expose=source[=target]
--share=source[=target]

For containers, --expose (resp. --share) exposes the file system source from the host system as the read-only (resp. writable) file system target within the container. If target is not specified, source is used as the target mount point in the container.

Пример ниже порождает Guile REPL в контейнере, в котором домашняя директория пользователя доступна только для чтения через директорию /exchange:

guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile

guix environment также поддерживает все обычные опции сборки, которые поддерживает команда guix build (see Стандартные параметры сборки), а также опции трансформации пакета (see Параметры преобразования пакета).


Next: , Previous: , Up: Разработка   [Contents][Index]

7.2 Вызов guix pack

Иногда бывает необходимо передать программу людям, которые (ещё!) не являются счастливыми обладателями Guix. Вы могли бы им рекомендовать заустить guix package -i something, но в данном случае это не подхлдит. Тогда guix pack решает вопрос.

Примечание: Если вы ищете способ обмена бинарниками между машинами, работающими с Guix, see Запуск guix copy, Запуск guix publish и Вызов guix archive.

Команда guix pack создаёт обёрнутый набор или программный набор: она создаёт архив tarball или другой архив, содержащий исполняемые файлы программного обеспечения, которое вас интересует, а также все его зависимости. Результирующий архив может использоваться на любой машине, которая не имеет Guix, а люди могут запустить совершенно такие же бинарники, как у вас в Guix. Набор создаётся со свойством воспроизводимости до бита, так что любой может проверить, что он действительно содержит результаты сборок, которые вы поставляете.

Например, чтобы создать набор, содержащий Guile, Emacs, Geiser и все их зависимости, можно запустить:

$ guix pack guile emacs geiser
…
/gnu/store/…-pack.tar.gz

Результатом будет архив tarball, содержащий директорию /gnu/store со всеми соответствующими пакетами. Результирующий архив содержат профиль с тремя запрошенными пакетами; профиль представляет то же самое, что можно создать командой guix package -i. Это механизм, который используется, собственно, для создания автономного (standalone) бинарного архива Guix (see Бинарная установка).

Пользователи этого пакета должны запускать /gnu/store/…-profile/bin/guile для запуска Guile, что может быть не удобно. Чтобы исправить это, можно создать, например, символическую ссылку /opt/gnu/bin на профиль:

guix pack -S /opt/gnu/bin=bin guile emacs geiser

Так пользователи смогут благополучно напечатать /opt/gnu/bin/guile, и всё хорошо.

What if the recipient of your pack does not have root privileges on their machine, and thus cannot unpack it in the root file system? In that case, you will want to use the --relocatable option (see below). This option produces relocatable binaries, meaning they they can be placed anywhere in the file system hierarchy: in the example above, users can unpack your tarball in their home directory and directly run ./opt/gnu/bin/guile.

В качестве альтернативы можно производить пакет в формате образа Docker, используя следующую команду:

guix pack -f docker -S /bin=bin guile guile-readline

Результатом будет архив, который можно передать команде docker load, followed by docker run:

docker load < file
docker run -ti guile-guile-readline /bin/guile

where file is the image returned by guix pack, and guile-guile-readline is its “image tag”. See the Docker documentation for more information.

Ещё одна опция производит образ SquashFS следующей командой:

guix pack -f squashfs bash guile emacs geiser

Результатом будет образ файловой системы SquashFS, который может непосредственно монтироваться как образ, содержащий контейнер файловой системы, с помощью контейнерного окружения Singularity, используя команды типа singularity shell или singularity exec.

Несколько опций командной строки позволяют вам переделывать ваш пакет:

--format=format
-f format

Произвести пакет в указанном формате format.

Возможные форматы:

tarball

Это формат по умолчанию. Он производит архив tarball, содержащий все заданные бинарники и символические ссылки.

docker

This produces a tarball that follows the Docker Image Specification. The “repository name” as it appears in the output of the docker images command is computed from package names passed on the command line or in the manifest file.

squashfs

Это создает образ SquashFS, содержащий все указанные двоичные файлы и символические ссылки, а также пустые точки монтирования для виртуальных файловых систем, таких как procfs.

Примечание: Singularity требует, чтобы вы указали /bin /sh в образе. По этой причине guix pack -f squashfs всегда подразумевает -S /bin=bin. Таким образом, вызов guix pack всегда должен начинаться с чего-то вроде:

guix pack -f squashfs bash …

Если вы забудете пакет bash (или аналогичный), singularity run и singularity exec выдаст бесполезное сообщение “нет такого файла или каталога”.

--relocatable
-R

Создавать relocatable binaries — то есть двоичные файлы, которые можно разместить в любом месте иерархии файловой системы и запускать оттуда.

Когда эта опция передается один раз, конечные двоичные файлы требуют поддержки user namespaces в ядре Linux; при передаче дважды13, Relocatable двоичные файлы возвращаются к другим методам, если пользовательские пространства имен недоступны, и по существу работают где угодно - см. ниже что под этим подразумевается.

Например, если вы создаете пакет, содержащий Bash, с помощью:

guix pack -RR -S /mybin=bin bash

... вы можете скопировать этот пакет на машину, на которой отсутствует Guix, и из своего домашнего каталога как обычный пользователь запустите:

tar xf pack.tar.gz
./mybin/sh

В этой оболочке, если вы наберете ls /gnu/store, вы заметите, что отобразятся /gnu/store и содержатся все зависимости bash, даже если на машине нет /gnu/store! Это, вероятно, самый простой способ установить программное обеспечение, созданное с помощью Guix, на машине, отличной от Guix.

Примечание: По умолчанию relocatable двоичные файлы полагаются на функцию user namespace ядра Linux, которая позволяет непривилегированным пользователям монтировать или изменять root. Старые версии Linux не поддерживали его, а некоторые дистрибутивы GNU/Linux его отключили.

Чтобы создать relocatable двоичные файлы, которые работают даже при отсутствии пользовательских пространств имен, передайте --relocatable или -R дважды. В этом случае двоичные файлы будут пытаться использовать пространство имен пользователей и возвращаться к другому механизму выполнения, если пространства имен пользователей не поддерживаются. Поддерживаются следующие механизмы выполнения:

default

Попробовать использовать пространства имен пользователей и вернуться к PRoot, если пространства имен пользователей не поддерживаются (см. ниже).

performance

Попробовать использовать пространства имен пользователей и вернуться к Fakechroot, если пространства имен пользователей не поддерживаются (см. ниже).

userns

Запустить программу через пользовательские пространства имен и прервать, если они не поддерживаются.

proot

Запустить PRoot. Программа PRoot обеспечивает необходимую поддержку виртуализации файловой системы. Это достигается с помощью системного вызова ptrace в запущенной программе. Преимущество этого подхода заключается в том, что это не требует специальной поддержки ядра, но это требует дополнительных затрат времени выполнения каждый раз, когда выполняется системный вызов.

fakechroot

Запустить Fakechroot. Fakechroot виртуализирует доступ к файловой системе путем перехвата вызовов функций библиотеки C, таких как open, stat, exec и т.п. В отличие от PRoot, накладных расходов очень мало. Однако это не всегда работает: например, некоторые обращения к файловой системе, сделанные из библиотеки C, не перехватываются, а обращения к файловой системе, сделанные через прямые системные вызовы, также не перехватываются, что приводит к нестабильному поведению.

При запуске обернутой программы вы можете явно запросить один из механизмов выполнения, перечисленных выше, установив соответствующую переменную среды GUIX_EXECUTION_ENGINE.

--entry-point=command

Используйте command в качестве точки входа конечного пакета, если формат пакета поддерживает это — в настоящее время docker и squashfs (Singularity) поддерживают это. command должна относиться к профилю, содержащемуся в пакете.

Точка входа указывает команду, которую по умолчанию автоматически запускают такие инструменты, как docker run или singularity run. Например, вы можете сделать:

guix pack -f docker --entry-point=bin/guile guile

Полученный пакет может быть легко импортирован, и запущен через docker run без дополнительных аргументов, пораждая bin/guile:

docker load -i pack.tar.gz
docker run image-id
--expression=expr
-e expr

Процедура, при выполнении которой возвращается пакет.

This has the same purpose as the same-named option in guix build (see --expression in guix build).

--manifest=file
-m file

Use the packages contained in the manifest object returned by the Scheme code in file. This option can be repeated several times, in which case the manifests are concatenated.

Она служит для того же, что и одноименная опция в guix package (see --manifest) и использует те же файлы манифеста. Она позволяет вам один раз определить набор пакетов и использовать его как для создания профилей, так и для создания архивов для использования на машинах, на которых не установлен Guix. Обратите внимание, что вы можете указать либо файл манифеста либо список пакетов, но не то и другое вместе.

--system=system
-s system

Предпринять попытку собрать систему system, т.е. i686-linux, вместо типа системы хоста сборки.

--target=triplet

Cross-сборка для triplet, который должен быть допустимым GNU triplet, например \ "aarch64-linux-gnu\" (see GNU configuration triplets in Autoconf).

--compression=tool
-C tool

Compress the resulting tarball using tool—one of gzip, zstd, bzip2, xz, lzip, or none for no compression.

--symlink=spec
-S spec

Добавить в пакет символические ссылки, указанные в spec. Эта опция может быть указана несколько раз.

spec имеет вид source=target, где source - это символическая ссылка, которая будет создана, а target - это цель символьной ссылки.

Например, -S /opt/gnu/bin=bin создает символическую ссылку /opt/gnu/bin, указывающую на подкаталог bin профиля.

--save-provenance

Сохранить информацию о происхождении пакетов, переданных в командной строке. Информация о происхождении включает в себя URL и фиксацию используемых каналов (see Каналы).

Информация о происхождении сохраняется в файле /gnu/store/…-profile/manifest в пакете вместе с обычными метаданными пакета - названием и версией каждого пакета, их propagated inputs и т.п. Это полезная информация для получателя pack, который исходя из нее знает, как (предположительно) был собран pack.

Этот параметр не включен по умолчанию, поскольку, как и временные метки, информация о происхождении не влияет на процесс сборки. Другими словами, существует бесконечное количество URL-адресов каналов и ID коммитов, которые могут привести к одному и тому же pack. Таким образом, запись таких “тихих” метаданных в output потенциально нарушает свойство побитовой воспроизводимости.

--root=file
-r file

Make file a symlink to the resulting pack, and register it as a garbage collector root.

--localstatedir
--profile-name=name

Включите в конечный пакет “локальный каталог состояния”, /var/guix и, в частности, профиль /var/guix/profiles/per-user/root/name — по умолчанию name - это guix-profile, что соответствует ~root/.guix-profile.

/var/guix содержит базу данных store (see Хранилище), а также корни сборщика мусора (see Вызов guix gc). Предоставление ее в pack означает, что store является “полным” и управляемым Guix; отсутствие в pack означает, что store “мертв”: пакеты нельзя добавить в него или удалить из него после извлечения pack.

Одним из вариантов использования является включающий себя двоичный архив Guix (see Бинарная установка).

--derivation
-d

Выведите имя derivation, которая создает pack.

--bootstrap

Использовать bootstrap бинарники для сборки пакета. Эта опция полезна только разработчикам Guix.

Кроме того, guix pack поддерживает все стандартные параметры сборки (see Стандартные параметры сборки) и все параметры преобразования пакетов (see Параметры преобразования пакета).


Next: , Previous: , Up: Разработка   [Contents][Index]

7.3 Тулчейн GCC

If you need a complete toolchain for compiling and linking C or C++ source code, use 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.

Пакет gfortran-toolchain предоставляет полный набор инструментов GCC для разработки Fortran. Для других языков используйте ‘guix search gcc toolchain’ (see Invoking guix package).


Previous: , Up: Разработка   [Contents][Index]

7.4 Invoking guix git authenticate

Команда guix git Authenticate аутентифицирует проверку Git по тому же правилу, что и для каналов (see channel authentication). То есть, начиная с данного коммита, он гарантирует, что все последующие коммиты подписаны ключом OpenPGP, отпечаток которого указан в файле .guix-authorizations его родительского коммита(ов).

Вы найдете эту команду полезной, если будете поддерживать канал. Но на самом деле этот механизм аутентификации полезен в более широком контексте, поэтому вы можете использовать его для репозиториев Git, которые не имеют ничего общего с Guix.

Основной синтаксис:

guix git authenticate commit signer [options…]

По умолчанию эта команда аутентифицирует проверку Git в текущем каталоге; она ничего не выводит и завершает работу с нулевым кодом в случае успеха и ненулевым в случае неудачи. commit выше обозначает первый коммит, в котором происходит аутентификация, а signer - это отпечаток открытого ключа OpenPGP, используемый для подписи commit. Вместе они образуют “channel introduction” (see channel introduction). Указанные ниже параметры позволяют вам точно настроить процесс.

--repository=directory
-r directory

Открыть репозиторий Git в directory вместо текущего каталога.

--keyring=reference
-k reference

Загрузить связку ключей OpenPGP из reference, ссылки на branch, например origin/keyring или my-keyring. branch должна содержать открытые ключи OpenPGP в файлах .key либо в двоичной форме, либо в “ASCII-armored” виде. По умолчанию связка ключей загружается из branch с именем keyring.

--stats

Отобразить статистику подписания commit’ов по завершению.

--cache-key=key

Ранее аутентифицированные коммиты кэшируются в файле под ~/.cache/guix/authentication. Эта опция заставляет хранить кеш в файле key в этом каталоге.

--historical-authorizations=file

По умолчанию любой коммит, родительский коммит которого не содержит файла .guix-authorizations, считается недостоверным. Напротив, эта опция учитывает авторизацию в file для любого коммита, в котором отсутствует .guix-authorizations. Формат file такой же, как у .guix-authorizations (see .guix-authorizations format).


Next: , Previous: , Up: Top   [Contents][Index]

8 Программный интерфейс

GNU Guix предоставляет несколько Scheme программных интерфейсов (API) для определения, сборки и запроса пакетов. Первый интерфейс позволяет пользователям писать высокоуровневые определения пакетов. Эти определения относятся к знакомым концепциям упаковки, таким как имя и версия пакета, его система сборки и зависимости. Затем эти определения можно превратить в конкретные действия по сборке.

Действия по сборке выполняются демоном Guix от имени пользователей. В стандартной настройке демон имеет доступ на запись в хранилище—каталог /gnu/store—, в то время как пользователи не имеют. Рекомендуемая установка также предусматривает, что демон выполняет сборки в chroot, под определенными пользователями сборки, чтобы минимизировать влияние на остальную систему.

Доступны API нижнего уровня для взаимодействия с демоном и хранилищем. Чтобы дать демону команду выполнить действие сборки, пользователи фактически предоставляют ему derivation. Derivation - это низкоуровневое представление действий сборки, которые должны быть предприняты, и среды, в которой они должны происходить - derivation’ы относятся к определениям пакетов, как сборка для программ на C. Термин “derivation” происходит от того факта, что результаты сборки производные от них.

В этой главе описываются все эти API по очереди, начиная с определений пакетов высокого уровня.


Next: , Up: Программный интерфейс   [Contents][Index]

8.1 Пакетные модули

С точки зрения программирования, определения пакетов дистрибутива GNU предоставляются модулями Guile в пространстве имен (gnu packages …) 14 (see Guile modules in GNU Guile Reference Manual)). Например, модуль (gnu packages emacs) экспортирует переменную с именем emacs, которая привязана к <package> объекту (see Описание пакетов).

Пространство имен модуля (gnu packages …) автоматически сканируется на наличие пакетов с помощью инструментов командной строки. Например, при запуске guix install emacs все модули (gnu packages …) сканируются до тех пор, пока не будет найден тот, который экспортирует объект пакета с именем emacs. Это средство поиска пакетов реализовано в модуле (gnu packages).

Пользователи могут хранить определения пакетов в модулях с разными именами - например, (my-packages emacs) 15. Есть два способа сделать эти определения пакетов видимыми для пользовательских интерфейсов:

  1. Добавить каталог, содержащий модули вашего пакета, в пути поиска с помощью флага -L команды guix package и другие команды (see Стандартные параметры сборки) или указать переменную окружения GUIX_PACKAGE_PATH, описанную ниже.
  2. Определить канал и настроить guix pull так, чтобы он учитывал его. Канал - это, по сути, репозиторий Git, содержащий модули пакетов. See Каналы, чтобы узнать больше о том, как определять и использовать каналы.

GUIX_PACKAGE_PATH работает аналогично другим переменным пути поиска:

Environment Variable: GUIX_PACKAGE_PATH

Это список каталогов, разделенных двоеточиями, для поиска дополнительных модулей пакета. Каталоги, перечисленные в этой переменной, имеют приоритет над собственными модулями дистрибутива.

Дистрибутив полностью bootstrapped и самодостаточный: каждый пакет построен исключительно на основе других пакетов в дистрибутиве. Корнем этого графа зависимостей является небольшой набор bootstrap бинарный файлы, предоставляемых модулем (gnu packages bootstrap). Для получения дополнительной информации о начальной загрузке see Начальная загрузка.


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.2 Описание пакетов

Интерфейс высокого уровня к определениям пакетов реализован в модулях (guix packages) и (guix build-system). Например, определение пакета или рецепта для пакета GNU Hello выглядит так:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (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)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs `(("gawk" ,gawk)))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

Не будучи Scheme экспертом, вы можете догадаться о значении различных полей. Это выражение связывает переменную hello с объектом <package>, который по сути является record (see Scheme records in GNU Guile Reference Manual). Этот объект пакета можно проверить с помощью процедур из модуля (guix packages); например, (package-name hello) возвращает—сюрприз!—"hello".

Если повезет, вы сможете импортировать часть или все определение интересующего вас пакета из другого репозитория с помощью команды guix import (see Запуск guix import).

В приведенном выше примере hello определен в собственном модуле (gnu packages hello). Технически в этом нет строгой необходимости, но это удобно: все пакеты, определенные в модулях под (gnu packages …), автоматически становятся известны инструментам командной строки (see Пакетные модули).

В приведенном выше определении пакета стоит отметить несколько моментов:

See ссылка на пакет, для полного описания возможных полей.

После того, как определение пакета введено, пакет может быть фактически собран с помощью инструмента командной строки guix build (see Запуск guix build), устраняя любые возникающие ошибки сборки (see Отладка ошибок сборки). Вы можете легко вернуться к определению пакета с помощью команды guix edit (see Запуск guix edit). See Принципы опакечивания для получения дополнительной информации о том, как тестировать определения пакетов, и Запуск guix lint для получения информации о том, как проверить определение на соответствие стилю. Наконец, see Каналы, чтобы узнать, как расширить дистрибутив, добавив собственные определения пакетов в “канал”.

Наконец, обновление определения пакета до новой исходной версии можно частично автоматизировать с помощью команды guix refresh (see Запуск guix refresh).

За кулисами derivation, соответствующая объекту <package>, сначала вычисляется с помощью процедуры package-diveration. Этот вывод хранится в файле .drv в каталоге /gnu/store. Действия сборки, которые он предписывает, затем могут быть реализованы с помощью процедуры build-derivations (see Хранилище).

Процедура Scheme: package-derivation store package [system]

Возвращает the <derivation> объект package для system (see Деривации).

package должен быть допустимым объектом <package>, а system должен быть строкой, обозначающей тип системы—например, "x86_64-linux" для системы GNU на базе x86_64 Linux. store должен быть подключен к демону, который работает с хранилищем (see Хранилище).

Точно так же можно вычислить derivation, которая cross собирает пакет для некоторой другой системы:

Процедура Scheme: package-cross-derivation store package target [system] Возвращает <derivation>

объект package cross-собранный из system в target.

target должен быть допустимым GNU triplet’ом, обозначающим желамое оборудование и операционную систему, например "aarch64-linux-gnu" (see Specifying Target Triplets in Autoconf).

Once you have package definitions, you can easily define variants of those packages. See Описание пакетов, for more on that.


Next: , Up: Описание пакетов   [Contents][Index]

8.2.1 package Ссылка

В этом разделе перечислены все параметры, доступные в объявлениях package (see Описание пакетов).

Тип данных: package

Это тип данных, представляющий рецепт пакета.

name

Название пакета в виде строки.

версия

Версия пакета, в виде строки.

источник

Объект, указывающий, как должен быть получен исходный код пакета. В большинстве случаев это объект origin, который обозначает файл, полученный из Интернета (see Интерфейс origin). Это также может быть любой другой объект, подобный файлу, например local-file, который представляет собой файл из локальной файловой системы (see local-file).

система сборки

Система сборки, которую следует использовать для сборки пакета (see Системы сборки).

arguments (default: '())

Аргументы, которые следует передать системе сборки. Это список, обычно содержащий последовательные пары ключевого слова и значения.

inputs (default: '())
native-inputs (default: '())
propagated-inputs (default: '())

В этих полях перечислены зависимости пакета. Каждый из них представляет собой список кортежей, где каждый кортеж имеет метку для ввода (строку) в качестве своего первого элемента, пакет, источник или derivation в качестве второго элемента и, необязательно, имя его вывода, которое следует использовать, которое по умолчанию является "out" (see Пакеты со множественным выходом, for more on package outputs). Например, в списке ниже указаны три входа:

`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;the "bin" output of Glib

Различие между native-inputs и inputs необходимо при рассмотрении кросс-компиляции. При кросс-компиляции зависимости, перечисленные в input, создаются для архитектуры target; и наоборот, зависимости, перечисленные в native-inputs, созданы для архитектуры машины, выполняющей сборку.

native-inputs обычно используется для перечисления инструментов, необходимых во время сборки, но не во время выполнения, таких как Autoconf, Automake, pkg-config, Gettext или Bison. guix lint может сообщить о вероятных ошибках в этой области (see Запуск guix lint).

Наконец, propagated-inputs похоже на inputs, но указанные пакеты будут автоматически установлены в профили (see the role of profiles in Guix) вместе с пакетом, которому они принадлежат (see guix package, for information on how guix package deals with propagated inputs).

Например, это необходимо при упаковке библиотеки C/C++, которой для компиляции требуются заголовки другой библиотеки, или когда файл pkg-config ссылается на другое поле через его Requires.

Другой пример использования propagated-inputs - это языки, в которых отсутствует возможность записывать путь поиска во время выполнения, аналогичный RUNPATH файлов ELF; сюда входят Guile, Python, Perl и другие. При упаковке библиотек, написанных на этих языках, убедитесь, что они могут найти код библиотеки, от которого они зависят, во время выполнения, указав зависимости времени выполнения в propagated-inputs, а не в inputs.

outputs (default: '("out"))

Список выходных имен пакета. See Пакеты со множественным выходом, для типичного использования дополнительных выходов.

native-search-paths (default: '())
search-paths (по умолчанию: '())

Список объектов search-path-specification, описывающих переменные среды пути поиска, учитываемые пакетом.

replacement (по умолчанию: #f)

Это должен быть либо #f, либо объект пакета, который будет использоваться как замена для этого пакета. See grafts, чтобы узнать подробности.

synopsis

Описание пакета в одну строку.

description

Более подробное описание пакета.

license

Лицензия пакета; значение из (guix licenses) или список таких значений.

home-page

URL-адрес домашней страницы пакета в виде строки.

supported-systems (default: %supported-systems)

Список систем, поддерживаемых пакетом, в виде строк вида architecture-kernel, например "x86_64-linux".

location (default: source location of the package form)

Исходное расположение пакета. Это полезно переопределить при наследовании от другого пакета, и в этом случае это поле не корректируется автоматически.

Scheme Syntax: this-package

При использовании в lexical scope определения поля пакета этот идентификатор преобразуется в определяемый пакет.

В приведенном ниже примере показано, как добавить пакет в качестве собственного ввода при кросс-компиляции:

(package
  (name "guile")
  ;; ...

  ;; When cross-compiled, Guile, for example, depends on
  ;; a native version of itself.  Add it here.
  (native-inputs (if (%current-target-system)
                     `(("self" ,this-package))
                     '())))

Ссылка на this-package вне определения пакета является ошибкой.

Поскольку пакеты являются обычными Scheme объектами, которые захватывают полный граф зависимостей и связанные процедуры сборки, часто бывает полезно написать процедуры, которые принимают пакет и возвращают его измененную версию в соответствии с некоторыми параметрами. Ниже приведены несколько примеров.

Scheme Procedure: package-with-c-toolchain package toolchain

Вернуть вариант package, в котором используется toolchain вместо стандартного набора инструментов GNU C/C++. toolchain должен быть списком входов (кортежи меток/пакетов), обеспечивающих эквивалентную функциональность, например, пакет gcc-toolchain.

Пример ниже возвращает вариант пакета hello, созданный с помощью GCC 10.x и остальной части GNU утилит (Binutils и библиотеки GNU C) вместо цепочки инструментов по умолчанию:

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

Инструменты сборки являются частью неявных входных данных пакетов - обычно они не указываются как часть различных полей “входных данных”, а вместо этого извлекается системой сборки. Следовательно, эта процедура работает путем изменения системы сборки package, так что она использует toolchain вместо значений по умолчанию. Системы сборки, чтобы узнать больше о системах сборки.


Previous: , Up: Описание пакетов   [Contents][Index]

8.2.2 origin Reference

Этот раздел документирует origins. Объявление origin определяет данные, которые должны быть “произведены”—обычно загружены—и чей хэш содержимого известен заранее. Origins в основном используются для представления исходного кода пакетов (see Описание пакетов). По этой причине форма origin позволяет вам объявлять исправления для применения к исходному коду, а также фрагменты кода для его изменения.

Тип данных: origin

Это тип данных, представляющий источник исходного кода.

uri

Объект, содержащий URI источника. Тип объекта зависит от method (см. ниже). Например, при использовании метода url-fetch для (guix download) допустимые значения uri: URL, представленный в виде строки, или их список.

метод

A monadic procedure that handles the given URI. The procedure must accept at least three arguments: the value of the uri field and the hash algorithm and hash value specified by the hash field. It must return a store item or a derivation in the store monad (see Устройство склада); most methods return a fixed-output derivation (see Деривации).

Обычно используемые методы включают url-fetch, который извлекает данные из URL-адреса, и git-fetch, который извлекает данные из репозитория Git (см. ниже).

sha256

Байт-вектор, содержащий хэш SHA-256 источника. Это эквивалент предоставлению объекта SHA256 content-hash в поле hash, описанном ниже.

hash

Объект content-hash источника—см. ниже, как использовать content-hash.

Вы можете получить эту информацию, используя guix download (see Запуск guix download) или guix hash (see Запуск guix hash).

file-name (по умолчанию: #f)

Имя файла, под которым должен быть сохранен исходный код. Когда это #f, в большинстве случаев будет использоваться разумное значение по умолчанию. В случае, если источник извлекается из URL-адреса, будет использоваться имя файла из URL-адреса. Для проверок контроля версий рекомендуется явно указывать имя файла, поскольку значение по умолчанию не очень информативно.

patches (по умолчанию: '())

Список имен файлов, источников или объектов подобных файлами (see file-like objects), указывающих на исправления, которые будут применены к источнику.

Данный список исправлений должен быть безвариативным. В частности, он не может зависеть от значения %current-system или %current-target-system.

snippet (по умолчанию: #f)

G-выражение (see G-Expressions) или S-выражение, которое будет выполнено в исходном каталоге. Это удобный способ изменить исходный код, иногда более удобный, чем патч.

patch-flags (по умолчанию: '("-p1"))

Список флагов командной строки, которые следует передать команде patch.

patch-inputs (по умолчанию: #f)"

Входные пакеты или derivation’ы для процесса исправления. Когда это #f, предоставляется обычный набор входных данных, необходимых для исправления, например GNU Patch.

modules (по умолчанию: '())

Список модулей Guile, которые должны быть загружены в процессе установки исправлений и при выполнении кода, в поле snippet.

patch-guile (по умолчанию: #f)

Пакет Guile, который следует использовать в процессе установки исправлений. Когда это #f, используется разумное значение по умолчанию.

Тип данных: content-hash value [algorithm]

Создать объект хэша содержимого для заданного algorithm и с value в качестве его хеш-значения. Если algorithm опущен, предполагается, что это sha256.

value может быть буквальной строкой, и в этом случае она декодируется с помощью base32, или может быть байтовым вектором.

The following forms are all equivalent:

(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
(content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
              sha256)
(content-hash (base32
               "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
(content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
              sha256)

Технически content-hash в настоящее время реализован как макрос. Он выполняет проверки работоспособности во время раскрытия макроса, когда это возможно, например, гарантирует, что value имеет правильный размер для algorithm.

Как мы видели выше, то, как именно извлекаются данные, на которые ссылается источник, определяется его полем method. Модуль (guix download) предоставляет наиболее распространенный метод url-fetch, описанный ниже.

Scheme Procedure: url-fetch url hash-algo hash [name] [#:executable? #f] Возвращает derivation с фиксированным выводом,

которая извлекает данные из url (строка или список строк, обозначающих альтернативные URL-адреса), который, как ожидается, будет иметь хэш hash типа hash-algo (символ). По умолчанию имя файла - это базовое имя URL-адреса; при желании name может указывать другое имя файла. Если executable? истинно, загруженный файл будет исполняемым.

Когда один из URL-адресов начинается с mirror://, тогда его хост-часть интерпретируется как имя схемы зеркала, взятой из %mirror-file.

В качестве альтернативного варианта, если URL-адрес начинается с file://, вернуть соответствующее имя файла в store.

Likewise, the (guix git-download) module defines the git-fetch origin method, which fetches data from a Git version control repository, and the git-reference data type to describe the repository and revision to fetch.

Scheme Procedure: git-fetch ref hash-algo hash

Вернуть derivation с фиксированным выводом, которая выбирает объект ref, <git-reference>. Ожидается, что на выходе будет рекурсивный хеш hash типа hash-algo (символ). Использовать name в качестве имени файла или общее имя, если #f.

Data Type: git-reference

This data type represents a Git reference for git-fetch to retrieve.

url

URL-адрес репозитория Git для клонирования.

commit

Эта строка обозначает либо коммит для загрузки (шестнадцатеричная строка, либо полный SHA1 коммит, либо “short” коммит строка; последнее не рекомендуется), либо тег.

recursive? (default: #f)

This Boolean indicates whether to recursively fetch Git sub-modules.

Пример ниже обозначает тег v2.10 репозитория GNU Hello:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "v2.10"))

Это эквивалентно приведенной ниже ссылке, которая явно называет коммит:

(git-reference
  (url "https://git.savannah.gnu.org/git/hello.git")
  (commit "dc7dc56a00e48fe6f231a58f6537139fe2908fb9"))

For Mercurial repositories, the module (guix hg-download) defines the hg-fetch origin method and hg-reference data type for support of the Mercurial version control system.

Scheme Procedure: hg-fetch ref hash-algo hash [name] Return a fixed-output derivation that fetches ref, a

<hg-reference> object. The output is expected to have recursive hash hash of type hash-algo (a symbol). Use name as the file name, or a generic name if #false.


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.3 Defining Package Variants

One of the nice things with Guix is that, given a package definition, you can easily derive variants of that package—for a different upstream version, with different dependencies, different compilation options, and so on. Some of these custom packages can be defined straight from the command line (see Параметры преобразования пакета). This section describes how to define package variants in code. This can be useful in “manifests” (see --manifest) and in your own package collection (see Создание канала), among others!

As discussed earlier, packages are first-class objects in the Scheme language. The (guix packages) module provides the package construct to define new package objects (see ссылка на пакет). The easiest way to define a package variant is using the inherit keyword together with package. This allows you to inherit from a package definition while overriding the fields you want.

For example, given the hello variable, which contains a definition for the current version of GNU Hello, here’s how you would define a variant for version 2.2 (released in 2006, it’s vintage!):

(use-modules (gnu packages base))    ;for 'hello'

(define hello-2.2
  (package
    (inherit hello)
    (version "2.2")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0lappv4slgb5spyqbh6yl5r013zv72yqg2pcl30mginf3wdqd8k9"))))))

The example above corresponds to what the --with-source package transformation option does. Essentially hello-2.2 preserves all the fields of hello, except version and source, which it overrides. Note that the original hello variable is still there, in the (gnu packages base) module, unchanged. When you define a custom package like this, you are really adding a new package definition; the original one remains available.

You can just as well define variants with a different set of dependencies than the original package. For example, the default gdb package depends on guile, but since that is an optional dependency, you can define a variant that removes that dependency like so:

(use-modules (gnu packages gdb)    ;for 'gdb'
             (srfi srfi-1))        ;for 'alist-delete'

(define gdb-sans-guile
  (package
    (inherit gdb)
    (inputs (alist-delete "guile"
                          (package-inputs gdb)))))

The alist-delete call above removes the tuple from the inputs field that has "guile" as its first element (see SRFI-1 Association Lists in GNU Guile Reference Manual).

In some cases, you may find it useful to write functions (“procedures”, in Scheme parlance) that return a package based on some parameters. For example, consider the luasocket library for the Lua programming language. We want to create luasocket packages for major versions of Lua. One way to do that is to define a procedure that takes a Lua package and returns a luasocket package that depends on it:

(define (make-lua-socket name lua)
  ;; Return a luasocket package built with LUA.
  (package
    (name name)
    (version "3.0")
    ;; several fields omitted
    (inputs
     `(("lua" ,lua)))
    (synopsis "Socket library for Lua")))

(define-public lua5.1-socket
  (make-lua-socket "lua5.1-socket" lua-5.1))

(define-public lua5.2-socket
  (make-lua-socket "lua5.2-socket" lua-5.2))

Here we have defined packages lua5.1-socket and lua5.2-socket by calling make-lua-socket with different arguments. See Procedures in GNU Guile Reference Manual, for more info on procedures. Having top-level public definitions for these two packages means that they can be referred to from the command line (see Пакетные модули).

These are pretty simple package variants. As a convenience, the (guix transformations) module provides a high-level interface that directly maps to the more sophisticated package transformation options (see Параметры преобразования пакета):

Scheme Procedure: options->transformation opts

Return a procedure that, when passed an object to build (package, derivation, etc.), applies the transformations specified by opts and returns the resulting objects. opts must be a list of symbol/string pairs such as:

((with-branch . "guile-gcrypt=master")
 (without-tests . "libgcrypt"))

Each symbol names a transformation and the corresponding string is an argument to that transformation.

For instance, a manifest equivalent to this command:

guix build guix \
  --with-branch=guile-gcrypt=master \
  --with-debug-info=zlib

... would look like this:

(use-modules (guix transformations))

(define transform
  ;; The package transformation procedure.
  (options->transformation
   '((with-branch . "guile-gcrypt=master")
     (with-debug-info . "zlib"))))

(packages->manifest
 (list (transform (specification->package "guix"))))

The options->transformation procedure is convenient, but it’s perhaps also not as flexible as you may like. How is it implemented? The astute reader probably noticed that most package transformation options go beyond the superficial changes shown in the first examples of this section: they involve input rewriting, whereby the dependency graph of a package is rewritten by replacing specific inputs by others.

Dependency graph rewriting, for the purposes of swapping packages in the graph, is what the package-input-rewriting procedure in (guix packages) implements.

Процедура Scheme: package-input-rewriting replacements [rewrite-name] [#:deep? #t] Возвращает процедуру, которая при передаче

пакета заменяет его прямые и косвенные зависимости, включая неявные входы, когда deep? истинна, согласно replacements. replacements - это список пар пакетов; первый элемент каждой пары - это заменяемый пакет, а второй - заменяющий.

При необходимости, rewrite-name - это процедура с одним аргументом, которая принимает имя пакета и возвращает его новое имя после перезаписи.

Рассмотрим пример:

(define libressl-instead-of-openssl
  ;; This is a procedure to replace OPENSSL by LIBRESSL,
  ;; recursively.
  (package-input-rewriting `((,openssl . ,libressl))))

(define git-with-libressl
  (libressl-instead-of-openssl git))

Здесь мы сначала определяем процедуру перезаписи, которая заменяет openssl на libressl. Затем мы используем это, чтобы определить вариант пакета git, который использует libressl вместо openssl. Это именно то, что делает параметр командной строки --with-input (see --with-input).

Следующий вариант package-input-rewriting может сопоставлять пакеты, подлежащие замене, по имени, а не по идентификатору.

Scheme Procedure: package-input-rewriting/spec replacements [#:deep? #t]

Возвращает процедуру, которая для данного пакета применяет заданные replacements ко всему графу пакета, включая неявные входные данные, если deep? не ложно. replacements - это список пары спецификация/процедуры; каждая спецификация - это спецификация пакета, такая как "gcc" или "guile@2", и каждая процедура берет соответствующий пакет и возвращает замену для этого пакета.

Приведенный выше пример можно переписать так:

(define libressl-instead-of-openssl
  ;; Replace all the packages called "openssl" with LibreSSL.
  (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

Ключевое отличие здесь в том, что на этот раз пакеты сопоставляются по спецификации, а не по идентичности. Другими словами, любой пакет в графе, который называется openssl, будет заменен.

Более общая процедура для перезаписи графа зависимостей пакетов - это package-mapping: она поддерживает произвольные изменения узлов в графе.

Scheme Procedure: package-mapping proc [cut?] [#:deep? #f]

Вернуть процедуру, которая для данного пакета применяет proc ко всем зависимым пакетам и возвращает полученный пакет. Процедура останавливает рекурсию, когда cut? возвращает истину для данного пакета. Когда deep? истинно, proc также применяется к неявным входным данным.


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.4 Системы сборки

В каждом определении пакета указывается система сборки и аргументы для этой системы сборки (see Описание пакетов). Это поле build-system представляет процедуру сборки пакета, а также неявные зависимости этой процедуры сборки.

Системы сборки - это объекты <build-system>. Интерфейс для их создания и управления ими предоставляется модулем (guix build-system), а фактические системы сборки экспортируются определенными модулями.

Под капотом системы сборки сначала компилируют объекты пакета в bag. bag похож на пакет, но с меньшим количеством украшений—другими словами, bag - это представление пакета нижнего уровня, которое включает в себя все входные данные этого пакета, включая те, которые были неявно добавлены система сборки. Это промежуточное представление затем компилируется в derivation (see Деривации). package-with-c-toolchain - это пример способа изменить неявные входные данные, которые использует система сборки пакета (see package-with-c-toolchain).

Системы сборки принимают необязательный список из arguments. В определениях пакетов они передаются через поле arguments (see Описание пакетов). Обычно это аргументы ключевого слова (see keyword arguments in Guile in GNU Guile Reference Manual). Значение этих аргументов обычно оценивается в build stratum—то есть процессом Guile, запущенным демоном (see Деривации).

Основная система сборки - это gnu-build-system, которая реализует стандартную процедуру сборки для GNU и многих других пакетов. Она предоставляется модулем (guix build-system gnu).

Scheme Variable: gnu-build-system

gnu-build-system представляет систему сборки GNU и ее варианты (see configuration and makefile conventions in GNU Coding Standards).

Вкратце, пакеты, использующие его, настраиваются, собираются и устанавливаются с помощью обычной последовательности команд ./ configure && make && make check && make install. На практике часто требуется несколько дополнительных шагов. Все эти шаги разбиты на отдельные фазы. See Фазы сборки, чтобы узнать больше о фазах сборки и способах их настройки.

Кроме того, эта система сборки гарантирует, что доступна “стандартная” среда для пакетов GNU. Сюда входят такие инструменты, как GCC, libc, Coreutils, Bash, Make, Diffutils, grep и sed (полный список см. в модуле (guix build-system gnu)). Мы называем их неявными входами пакета, потому что в определениях пакетов они не упоминаются.

This build system supports a number of keyword arguments, which can be passed via the arguments field of a package. Here are some of the main parameters:

#:phases

This argument specifies build-side code that evaluates to an alist of build phases. See Фазы сборки, for more information.

#:configure-flags

This is a list of flags (strings) passed to the configure script. See Описание пакетов, for an example.

#:make-flags

This list of strings contains flags passed as arguments to make invocations in the build, check, and install phases.

#:out-of-source?

This Boolean, #f by default, indicates whether to run builds in a build directory separate from the source tree.

When it is true, the configure phase creates a separate build directory, changes to that directory, and runs the configure script from there. This is useful for packages that require it, such as glibc.

#:tests?

This Boolean, #t by default, indicates whether the check phase should run the package’s test suite.

#:test-target

This string, "check" by default, gives the name of the makefile target used by the check phase.

#:parallel-build?
#:parallel-tests?

These Boolean values specify whether to build, respectively run the test suite, in parallel, with the -j flag of make. When they are true, make is passed -jn, where n is the number specified as the --cores option of guix-daemon or that of the guix client command (see --cores).

#:validate-runpath?

This Boolean, #t by default, determines whether to “validate” the RUNPATH of ELF binaries (.so shared libraries as well as executables) previously installed by the install phase.

This validation step consists in making sure that all the shared libraries needed by an ELF binaries, which are listed as DT_NEEDED entries in its PT_DYNAMIC segment, appear in the DT_RUNPATH entry of that binary. In other words, it ensures that running or using those binaries will not result in a “file not found” error at run time. See -rpath in The GNU Linker, for more information on RUNPATH.

#:substitutable?

This Boolean, #t by default, tells whether the package outputs should be substitutable—i.e., whether users should be able to obtain substitutes for them instead of building locally (see Подстановки).

#:allowed-references
#:disallowed-references

When true, these arguments must be a list of dependencies that must not appear among the references of the build results. If, upon build completion, some of these references are retained, the build process fails.

This is useful to ensure that a package does not erroneously keep a reference to some of it build-time inputs, in cases where doing so would, for example, unnecessarily increase its size (see Запуск guix size).

Most other build systems support these keyword arguments.

Другие объекты <build-system> определены для поддержки других соглашений и инструментов, используемых пакетами свободного программного обеспечения. Они наследуют большую часть gnu-build-system и различаются в основном набором входных данных, неявно добавляемых в процесс сборки, и списком выполняемых фаз. Некоторые из этих систем сборки перечислены ниже.

Scheme Variable: ant-build-system

Эта переменная экспортируется (guix build-system ant). Она реализует процедуру сборки пакетов Java, которые можно собрать с помощью Ant build tool.

Она добавляет к набору входных данных как ant, так и Java Development Kit (JDK), предоставленные пакетом icedtea. Различные пакеты можно указать с помощью параметров #:ant и #:jdk соответственно.

Когда исходный пакет не предоставляет подходящий файл сборки Ant, параметр #:jar-name можно использовать для создания минимального файла сборки Ant build.xml с задачами для создания указанного архива jar. В этом случае параметр #:source-dir можно использовать для указания подкаталога источника, по умолчанию - src.

The #:main-class parameter can be used with the minimal ant buildfile to specify the main class of the resulting jar. This makes the jar file executable. The #:test-include parameter can be used to specify the list of junit tests to run. It defaults to (list "**/*Test.java"). The #:test-exclude can be used to disable some tests. It defaults to (list "**/Abstract*.java"), because abstract classes cannot be run as tests.

Параметр #:build-target можно использовать для указания задачи Ant, которая должна выполняться на этапе build. По умолчанию будет запущена задача jar.

Scheme Variable: android-ndk-build-system

Эта переменная экспортируется (guix build-system android-ndk). Она реализует процедуру сборки пакетов Android NDK (собственный комплект разработки) с использованием процесса сборки, специфичного для Guix.

Система сборки предполагает, что пакеты устанавливают свои файлы общедоступного интерфейса (заголовки) в подкаталог include вывода out, а их библиотеки - в подкаталог lib вывода out.

Также предполагается, что объединение всех зависимостей пакета не имеет конфликтующих файлов.

В настоящее время кросс-компиляция не поддерживается, поэтому сейчас предполагается, что библиотеки и файлы заголовков являются хост-инструментами.

Scheme Variable: asdf-build-system/source
Scheme Variable: asdf-build-system/sbcl
Scheme Variable: asdf-build-system/ecl

These variables, exported by (guix build-system asdf), implement build procedures for Common Lisp packages using “ASDF”. ASDF is a system definition facility for Common Lisp programs and libraries.

The asdf-build-system/source system installs the packages in source form, and can be loaded using any common lisp implementation, via ASDF. The others, such as asdf-build-system/sbcl, install binary systems in the format which a particular implementation understands. These build systems can also be used to produce executable programs, or lisp images which contain a set of packages pre-loaded.

В системе сборки используются соглашения об именах. Для бинарных пакетов перед именем пакета должен стоять префикс реализации lisp, например sbcl- для asdf-build-system/sbcl.

Кроме того, соответствующий исходный пакет должен быть помечен с использованием того же соглашения, что и пакеты python (см. Модули Python), с использованием префикса cl-.

In order to create executable programs and images, the build-side procedures build-program and build-image can be used. They should be called in a build phase after the create-asdf-configuration phase, so that the system which was just built can be used within the resulting image. build-program requires a list of Common Lisp expressions to be passed as the #:entry-program argument.

By default, all the .asd files present in the sources are read to find system definitions. The #:asd-files parameter can be used to specify the list of .asd files to read. Furthermore, if the package defines a system for its tests in a separate file, it will be loaded before the tests are run if it is specified by the #:test-asd-file parameter. If it is not set, the files <system>-tests.asd, <system>-test.asd, tests.asd, and test.asd will be tried if they exist.

If for some reason the package must be named in a different way than the naming conventions suggest, or if several systems must be compiled, the #:asd-systems parameter can be used to specify the list of system names.

Scheme Variable: cargo-build-system

Эта переменная экспортируется (guix build-system cargo). Она поддерживает сборку пакетов с использованием Cargo, инструмента сборки языка программирования Rust.

Она добавляет rustc и cargo к набору входных данных. Другой пакет Rust можно указать с помощью параметра #:rust.

Regular cargo dependencies should be added to the package definition similarly to other packages; those needed only at build time to native-inputs, others to inputs. If you need to add source-only crates then you should add them to via the #:cargo-inputs parameter as a list of name and spec pairs, where the spec can be a package or a source definition. Note that the spec must evaluate to a path to a gzipped tarball which includes a Cargo.toml file at its root, or it will be ignored. Similarly, cargo dev-dependencies should be added to the package definition via the #:cargo-development-inputs parameter.

In its configure phase, this build system will make any source inputs specified in the #:cargo-inputs and #:cargo-development-inputs parameters available to cargo. It will also remove an included Cargo.lock file to be recreated by cargo during the build phase. The package phase will run cargo package to create a source crate for future use. The install phase installs the binaries defined by the crate. Unless install-source? #f is defined it will also install a source crate repository of itself and unpacked sources, to ease in future hacking on rust packages.

Scheme Variable: chicken-build-system

This variable is exported by (guix build-system chicken). It builds CHICKEN Scheme modules, also called “eggs” or “extensions”. CHICKEN generates C source code, which then gets compiled by a C compiler, in this case GCC.

Эта система сборки добавляет chicken к входным данным (inputs) пакета, а также к пакетам gnu-build-system.

The build system can’t (yet) deduce the egg’s name automatically, so just like with go-build-system and its #:import-path, you should define #:egg-name in the package’s arguments field.

For example, if you are packaging the srfi-1 egg:

(arguments '(#:egg-name "srfi-1"))

Egg dependencies must be defined in propagated-inputs, not inputs because CHICKEN doesn’t embed absolute references in compiled eggs. Test dependencies should go to native-inputs, as usual.

Scheme Variable: copy-build-system

Эта переменная экспортируется в (guix build-system copy). Она поддерживает сборку простых пакетов, которые не требуют большой компиляции, в основном просто перемещения файлов.

Она добавляет большую часть пакетов gnu-build-system в набор входных данных. По этой причине copy-build-system не требуется весь шаблонный код, часто необходимый для trivial-build-system.

Чтобы еще больше упростить процесс установки файла, предоставляется аргумент #:install-plan, позволяющий упаковщику указывать, какие файлы куда установить. План установки представляет собой список (source target [filters]). filters необязательны.

Примеры:

Scheme Variable: clojure-build-system

Эта переменная экспортируется (guix build-system clojure). Она реализует простую процедуру сборки пакетов Clojure с использованием простого старого compile в Clojure. Кросс-компиляция пока не поддерживается.

Она добавляет clojure, icedtea и zip к набору входных данных. Различные пакеты можно указать с помощью параметров #:clojure, #:jdk и #:zip соответственно.

Список исходных каталогов, тестовых каталогов и имен jar-файлов можно указать с помощью параметров #:source-dirs, #:test-dirs и #:jar-names соответственно. Каталог компиляции и основной класс можно указать с помощью параметров #:compile-dir и #:main-class соответственно. Остальные параметры описаны ниже.

Эта система сборки является расширением ant-build-system, но со следующими изменениями:

build

На этом этапе вызывается compile в Clojure для компиляции исходных файлов и запускается jar для создания jar-файлов как из исходных файлов, так и из скомпилированных файлов в соответствии со списком включения и списком исключений, указанным в #:aot-include и #:aot-exclude соответственно. Список исключений имеет приоритет над списком включения. Эти списки состоят из символов, представляющих библиотеки Clojure, или специального ключевого слова #:all, представляющего все библиотеки Clojure, находящиеся в исходных каталогах. Параметр #:omit-source? определяет, следует ли включать исходники в jar-файлы.

check

На этом этапе выполняются тесты в соответствии со списком включения и списком исключений, указанными в #:test-include и #:test-exclude соответственно. Их значения аналогичны значениям #:aot-include и #:aot-exclude, за исключением того, что специальное ключевое слово #:all теперь обозначает все библиотеки Clojure, находящиеся в каталогах test. Параметр #:tests? определяет, нужно ли запускать тесты.

установка

На этом этапе устанавливаются все созданные ранее jars.

Помимо вышесказанного, эта система сборки также содержит дополнительную фазу:

install-doc

На этом этапе устанавливаются все файлы верхнего уровня с базовым именем, совпадающим с %doc-regex. Другое регулярное выражение можно указать с помощью параметра #:doc-regex. Все файлы (рекурсивно) в каталогах документации, указанные в #:doc-dirs, также устанавливаются.

Scheme переменная: cmake-build-system

Эта переменная экспортируется (guix build-system cmake). Она реализует процедуру сборки пакетов с использованием инструмента сборки CMake.

Она автоматически добавляет пакет cmake в набор входных данных. Какой пакет используется, можно указать с помощью параметра #:cmake.

Параметр #:configure-flags используется как список флагов, переданных команде cmake. Параметр #:build-type абстрактно определяет флаги, передаваемые компилятору; по умолчанию используется "RelWithDebInfo" (сокращение от “release mode с отладочной информацией”), что примерно означает, что код компилируется с помощью -O2 -g, как в случае пакетов на основе Autoconf по умолчанию.

Scheme переменная: dune-build-system

Эта переменная экспортируется в (guix build-system dune). Она поддерживает сборку пакетов с использованием Dune, инструмента сборки для языка программирования OCaml. Она реализована как расширение ocaml-build-system, описанную ниже. Таким образом, в эту систему сборки можно передать параметры #:ocaml и #:findlib.

Она автоматически добавляет пакет dune в набор входных данных. Какой пакет используется, можно указать с помощью параметра #:dune.

Фаза configure отсутствует, потому что dune пакеты обычно не нужно настраивать. Параметр #:build-flags используется как список флагов, переданных команде dune во время сборки.

Параметр #:jbuild? можно передать для использования команды jbuild вместо более новой команды dune при сборке пакета. Его значение по умолчанию - #f.

Параметр #:package может быть передан для указания имени пакета, что полезно, когда пакет содержит несколько пакетов, и вы хотите создать только один из них. Это эквивалентно передаче аргумента -p в dune.

Scheme переменная: go-build-system

Эта переменная экспортируется (guix build-system go). Онf реализует процедуру сборки пакетов Go с использованием стандартного механизмов сборки Go.

Ожидается, что пользователь предоставит значение для ключа #:import-path и, в некоторых случаях, #:unpack-path. import path соответствует пути к файловой системе, ожидаемому сценариями сборки пакета и любыми ссылочными пакетами, и обеспечивает уникальный способ ссылки на Go пакет. Обычно он основан на комбинации удаленного URI исходного кода пакета и иерархической структуры файловой системы. В некоторых случаях вам нужно будет распаковать исходный код пакета в другую структуру каталогов, отличную от той, которая указана в пути импорта, и в таких случаях следует использовать #:unpack-path.

Пакеты, которые предоставляют библиотеки Go, должны устанавливать свой исходный код во встроенные выходные данные. Ключ #:install-source?, который по умолчанию равен #t, определяет, установливается ли исходный код. Для пакетов, которые предоставляют только исполняемые файлы, может быть установлено значение #f.

Scheme переменная: glib-or-gtk-build-system

Эта переменная экспортируется в (guix build-system glib-or-gtk). Она предназначена для использования с пакетами, использующими GLib или GTK+.

Эта система сборки добавляет следующие две фазы к тем, которые определены в gnu-build-system:

glib-or-gtk-wrap

Фаза glib-or-gtk-wrap гарантирует, что программы в bin/ смогут найти GLib “schemas” и модули GTK+. Это достигается путем включения программ в сценарии запуска, которые соответствующим образом устанавливают переменные среды XDG_DATA_DIRS и GTK_PATH.

Можно исключить определенные выходные данные пакета из этого процесса упаковки, указав их имена в параметре #:glib-or-gtk-wrap-excluded-output. Это полезно, когда известно, что выходной файл не содержит двоичных файлов GLib или GTK+, и где wrapping может произвольно добавить зависимость этого вывода от GLib и GTK+.

glib-or-gtk-compile-schemas

Фаза glib-or-gtk-compile-schemas гарантирует, что все GSettings schemas в GLib скомпилированы. Компиляция выполняется программой glib-compile-schemas. Она предоставляется пакетом glib:bin, который автоматически импортируется системой сборки. Пакет glib, предоставляющий glib-compile-schemas, можно указать с помощью параметра #:glib.

Обе фазы выполняются после фазы install.

Scheme переменная: guile-build-system

Эта система сборки предназначена для пакетов Guile, которые состоят исключительно из кода Scheme и настолько скудны, что у них даже нет make-файла, не говоря уже о сценарии configure. Она компилирует Scheme код с помощью guild compile (see Compilation in GNU Guile Reference Manual) и устанавливает файлы .scm и .go в нужное место. Она также устанавливает документацию.

Эта система сборки поддерживает кросс-компиляцию с использованием параметра --target в ‘guild compile’.

Пакеты, созданные с помощью guile-build-system, должны содержать пакет Guile в поле native-inputs.

Scheme переменная: julia-build-system

This variable is exported by (guix build-system julia). It implements the build procedure used by julia packages, which essentially is similar to running ‘julia -e 'using Pkg; Pkg.add(package)'’ in an environment where JULIA_LOAD_PATH contains the paths to all Julia package inputs. Tests are run by calling /test/runtests.jl.

The Julia package name is read from the file Project.toml. This value can be overridden by passing the argument #:julia-package-name (which must be correctly capitalized).

Julia packages usually manage their binary dependencies via JLLWrappers.jl, a Julia package that creates a module (named after the wrapped library followed by _jll.jl.

To add the binary path _jll.jl packages, you need to patch the files under src/wrappers/, replacing the call to the macro JLLWrappers.@generate_wrapper_header, adding as a second argument containing the store path the binary.

As an example, in the MbedTLS Julia package, we add a build phase (see Фазы сборки) to insert the absolute file name of the wrapped MbedTLS package:

(add-after 'unpack 'override-binary-path
  (lambda* (#:key inputs #:allow-other-keys)
    (for-each (lambda (wrapper)
                (substitute* wrapper
                  (("generate_wrapper_header.*")
                   (string-append
                    "generate_wrapper_header(\"MbedTLS\", \""
                    (assoc-ref inputs "mbedtls-apache") "\")\n"))))
              ;; There's a Julia file for each platform, override them all.
              (find-files "src/wrappers/" "\\.jl$"))))

Some older packages that aren’t using Package.toml yet, will require this file to be created, too. The function julia-create-package-toml helps creating the file. You need to pass the outputs and the source of the package, it’s name (the same as the file-name parameter), the package uuid, the package version, and a list of dependencies specified by their name and their uuid.

Scheme Variable: maven-build-system

Эта переменная экспортируется в (guix build-system maven). Она реализует процедуру сборки пакетов Maven. Maven - это инструмент для управления зависимостями и жизненным циклом Java. Пользователь Maven указывает зависимости и плагины в файле pom.xml, который читает Maven. Когда Maven не имеет одной из зависимостей или плагинов в своем репозитории, он загружает их и использует для сборки пакета.

Система сборки maven гарантирует, что maven не будет пытаться загрузить какие-либо зависимости, работая в offline режиме. Maven завершится ошибкой, если зависимость отсутствует. Перед запуском Maven pom.xml (и подпроекты) модифицируются, чтобы указать версию зависимостей и плагинов, которые соответствуют версиям, доступным в среде сборки guix. Зависимости и плагины должны быть установлены в поддельном репозитории maven по адресу lib/m2 и перед запуском maven привязаны к соответствующему репозиторию. Maven получает указание использовать этот репозиторий для сборки и устанавливает туда созданные артефакты. Измененные файлы копируются в каталог lib/m2 выходных данных пакета.

Вы можете указать файл pom.xml с аргументом #:pom-file или позволить системе сборки использовать файл pom.xml по умолчанию в источниках.

Если вам нужно указать версию зависимости вручную, вы можете использовать аргумент #:local-packages. Он принимает список ассоциаций, где ключ - это groupId пакета, а его значение - это список ассоциаций, где ключ - это artifactId пакета, а его значение - это версия, которую вы хотите переопределить в pom.xml.

Некоторые пакеты используют зависимости или плагины, которые не используются ни во время выполнения, ни во время сборки в Guix. Вы можете изменить файл pom.xml, чтобы удалить их, используя аргумент #:exclude. Его значение - это список ассоциаций, где ключ - это groupId плагина или зависимости, которые вы хотите удалить, а значение - это список artifactId, которые вы хотите удалить.

Вы можете переопределить пакеты по умолчанию jdk и maven с помощью соответствующего аргумента, #:jdk и #:maven.

Аргумент #:maven-plugins - это список подключаемых модулей maven, используемых во время сборки, в том же формате, что и поля inputs в объявлении пакета. Его значение по умолчанию - (default-maven-plugins), которое также экспортируется.

Scheme переменная: minify-build-system

Эта переменная экспортируется в (guix build-system minify). Она реализует процедуру минификации для простых пакетов JavaScript.

Он добавляет uglify-js к набору входных данных и использует его для сжатия всех файлов JavaScript в каталоге src. Другой minifier пакет можно указать с помощью параметра #:uglify-js, но ожидается, что этот пакет запишет минимизированный код в стандартный вывод.

Когда не все входные файлы JavaScript находятся в каталоге src, можно использовать параметр #:javascript-files, чтобы указать список имен файлов для передачи в minifier.

Scheme переменная: ocaml-build-system

Эта переменная экспортируется в (guix build-system ocaml). Она реализует процедуру сборки пакетов OCaml, которая заключается в выборе правильного набора команд для запуска для каждого пакета. Пакеты OCaml могут ожидать выполнения множества различных команд. Эта система сборки попробует некоторые из них.

Если в пакете есть файл setup.ml на верхнем уровне, он будет запускать ocaml setup.ml -configure, ocaml setup.ml -build и ocaml setup.ml -install. Система сборки предполагает, что этот файл был сгенерирован OASIS, и позаботится об установке префикса и включении тестов, если они не отключены. Вы можете передать флаги конфигурации и сборки с помощью #:configure-flags и #:build-flags. Ключ #:test-flags может быть передан для изменения набора флагов, используемых для включения тестов. Ключ #:use-make? можно использовать для обхода этой системы на этапах сборки и установки.

Когда в пакете есть файл configure, предполагается, что это созданный вручную скрипт настройки, для которого требуется другой формат аргументов, чем в gnu-build-system. Вы можете добавить дополнительные флаги с помощью клавиши #:configure-flags.

Когда в пакете есть файл Makefile (или #:use-make? - это #t), он будет использоваться, и дополнительные флаги могут быть переданы на этапы сборки и установки с #:make-flags ключом.

Наконец, некоторые пакеты не имеют этих файлов и используют стандартное расположение для своей системы сборки. В этом случае система сборки запустит ocaml pkg/pkg.ml или ocaml pkg/build.ml и позаботится о предоставлении пути к необходимому модулю findlib. Дополнительные флаги можно передать с помощью ключа #:build-flags. Об установке позаботится opam-installer. В этом случае пакет opam необходимо добавить в поле native-inputs в определении пакета.

Обратите внимание, что большинство пакетов OCaml предполагают, что они будут установлены в том же каталоге, что и OCaml, что не является тем, что мы хотим в guix. В частности, они устанавливают файлы .so в каталог своего модуля, что обычно нормально, потому что он находится в каталоге компилятора OCaml. Однако в guix эти библиотеки нельзя найти, и мы используем CAML_LD_LIBRARY_PATH. Эта переменная указывает на lib/ocaml/site-lib/stubslibs, и именно здесь должны быть установлены библиотеки .so.

Scheme переменная: python-build-system

Эта переменная экспортируется в (guix build-system python). Она реализует более или менее стандартную процедуру сборки, используемую пакетами Python, которая заключается в запуске python setup.py build, а затем python setup.py install --prefix=/gnu/store/….

Для пакетов, которые устанавливают само-достаточные программы Python в bin/, она заботится об обертке этих программ, чтобы их переменная среды PYTHONPATH указывала на все библиотеки Python, от которых они зависят.

Какой пакет Python используется для сборки, можно указать с помощью параметра #:python. Это полезный способ принудительно создать пакет для определенной версии интерпретатора Python, что может потребоваться, если пакет совместим только с одной версией интерпретатора.

По умолчанию guix вызывает setup.py под управлением setuptools, как и pip. Некоторые пакеты несовместимы с setuptools (и pip), поэтому вы можете отключить это, установив для параметра #:use-setuptools? значение #f.

Scheme Variable: perl-build-system

Эта переменная экспортируется в (guix build-system perl). Она реализует стандартную процедуру сборки для пакетов Perl, которая заключается либо в запуске perl Build.PL --prefix=/gnu/store/…, за которым следуют Build и Build install; или при запуске perl Makefile.PL PREFIX=/gnu/store/…, за которым следуют make и make install, в зависимости от того, какой из Build.PL или Makefile.PL присутствует в дистрибутиве пакета. Предпочтение отдается первому, если в дистрибутиве пакета есть и Build.PL, и Makefile.PL. Это предпочтение можно отменить, указав #t для параметра #:make-maker?.

Первоначальный вызов perl Makefile.PL или perl Build.PL передает флаги, указанные в параметре #:make-maker-flags или #:module-build-flags, соответственно.

Какой пакет Perl используется, можно указать с помощью #:perl.

Scheme Variable: renpy-build-system

This variable is exported by (guix build-system renpy). It implements the more or less standard build procedure used by Ren’py games, which consists of loading #:game once, thereby creating bytecode for it.

It further creates a wrapper script in bin/ and a desktop entry in share/applications, both of which can be used to launch the game.

Which Ren’py package is used can be specified with #:renpy. Games can also be installed in outputs other than “out” by using #:output.

Scheme переменная: qt-build-system

Эта переменная экспортируется в (guix build-system qt). Она предназначена для использования с приложениями, использующими Qt или KDE.

Эта система сборки добавляет следующие две фазы к тем, которые определены в cmake-build-system:

check-setup

Фаза check-setup подготавливает среду к запуску проверок, которые обычно используются тестовыми программами Qt. Пока это устанавливает только некоторые переменные среды: QT_QPA_PLATFORM=offscreen, DBUS_FATAL_WARNINGS=0 и CTEST_OUTPUT_ON_FAILURE=1.

Этот этап добавляется перед этапом check. Это отдельный этап для облегчения настройки.

qt-wrap

Фаза qt-wrap ищет пути к плагинам Qt5, пути QML и некоторый XDG во входных и выходных данных. Если путь найден, все программы в выходных каталогах bin/, sbin/, libexec/ и lib/libexec/ заключены в сценарии, определяющие необходимые environment переменные.

Можно исключить определенные выходные данные пакета из этого процесса упаковки, указав их имена в параметре #:qt-wrap-excluded-output. Это полезно, когда известно, что вывод не содержит никаких двоичных файлов Qt, и когда обертка может произвольно добавить зависимость этого вывода от Qt, KDE и т.п.

Эта фаза добавляется после фазы install.

Scheme Variable: r-build-system

Эта переменная экспортируется в (guix build-system r). Она реализует процедуру сборки, используемую пакетами R, которая, по сути, немного больше, чем запуск ‘R CMD INSTALL --library=/gnu/store/…’ в среде, где R_LIBS_SITE содержит пути ко всем входам пакета R. Тесты запускаются после установки с использованием R-функции tools::testInstalledPackage.

Scheme переменная: rakudo-build-system

Эта переменная экспортируется (guix build-system rakudo). Которая реализует систем сборки, используемую Rakudo для Perl6 пакетов. Она устанавливает: пакет в /gnu/store/…/NAME-VERSION/share/perl6; двоичные файлы, библиотеки и ресурсы; помещает файлы в bin/. Тесты можно пропустить, передав #f параметру tests?.

Какой пакет rakudo используется, можно указать с помощью rakudo. Какой пакет perl6-tap-harness, используемый для тестов, можно указать с помощью #:verify6 или удалить, передав #f в параметр with-verify6?. Какой пакет perl6-zef, используемый для тестирования и установки, можно указать с помощью #:zef или удалить, передав #f в параметр with-zef?.

Scheme переменная: texlive-build-system

Эта переменная экспортируется в (guix build-system texlive). Она используется для сборки пакетов TeX в batch режиме с указанным движком. Система сборки устанавливает переменную TEXINPUTS для поиска всех исходных файлов TeX во входных данных.

По умолчанию она запускает luatex для всех файлов, заканчивающихся на ins. Другой механизм и формат можно указать с помощью аргумента #:tex-format. Различные цели сборки могут быть указаны с помощью аргумента #:build-target, который ожидает список имен файлов. Система сборки добавляет к входам только texlive-bin и texlive-latex-base (оба из (gnu packages tex). Оба могут быть переопределены с помощью аргументов #:texlive-bin и #:texlive-latex-base соответственно.

Параметр #:tex-directory сообщает системе сборки, где установить созданные файлы в дереве texmf.

Scheme переменная: ruby-build-system

Эта переменная экспортируется в (guix build-system ruby). Она реализует процедуру сборки RubyGems, используемую пакетами Ruby, которая включает запуск gem build, за которым следует gem install.

Поле source пакета, использующего эту систему сборки, обычно ссылается на gem архив, поскольку это формат, который разработчики Ruby используют при выпуске своего программного обеспечения. Система сборки распаковывает gem архив, потенциально исправляет исходный код, запускает набор тестов, переупаковывает gem и устанавливает его. Кроме того, на каталоги и архивы можно ссылаться, чтобы можно было создавать unreleased gem’ы из Git или традиционного архива с исходным кодом.

Какой пакет Ruby используется, можно указать с помощью параметра #:ruby. Список дополнительных флагов, передаваемых команде gem, можно указать с помощью параметра #:gem-flags.

Scheme переменная: waf-build-system

Эта переменная экспортируется в (guix build-system waf). Она реализует процедуру сборки вокруг сценария waf. Общие этапы—configure, build и install—реализуются путем передачи их имен в качестве аргументов сценарию waf.

Скрипт waf выполняется интерпретатором Python. Какой пакет Python используется для запуска сценария, можно указать с помощью параметра #:python.

Scheme переменная: scons-build-system

Эта переменная экспортируется в (guix build-system scons). Она реализует процедуру сборки, используемую инструментом сборки программного обеспечения SCons. Эта система сборки запускает scons для сборки пакета, scons test для запуска тестов и затем scons install для установки пакета.

Дополнительные флаги, передаваемые в scons, можно указать с помощью параметра #:scons-flags. Цели сборки и установки по умолчанию могут быть переопределены с помощью #:build-target и #:install-target соответственно. Версия Python, используемая для запуска SCons, может быть указана путем выбора соответствующего пакета SCons с параметром #:scons.

Scheme переменная: haskell-build-system

Эта переменная экспортируется в (guix build-system haskell). Она реализует процедуру сборки Cabal, используемую пакетами Haskell, которая включает запуск runhaskell Setup.hs configure --prefix=/gnu/store/… и runhaskell Setup.hs build. Вместо установки пакета путем запуска runhaskell Setup.hs install, чтобы избежать попыток регистрации библиотек в каталоге хранилища компилятора только для чтения, система сборки использует runhaskell Setup.hs copy, за которым следует runhaskell Setup.hs register. Кроме того, система сборки генерирует документацию по пакету, запуская runhaskell Setup.hs haddock, если только #:haddock? #f пройден. Дополнительные параметры можно передать с помощью параметра #:haddock-flags. Если файл Setup.hs не найден, система сборки вместо этого ищет Setup.lhs.

Какой компилятор Haskell используется, можно указать с помощью параметра #:haskell, который по умолчанию равен ghc.

Scheme переменная: dub-build-system

Эта переменная экспортируется в (guix build-system dub). Она реализует процедуру сборки Dub, используемую пакетами D, которая включает запуск dub build и dub run. Установка осуществляется путем копирования файлов вручную.

Какой компилятор D используется, можно указать с помощью параметра #:ldc, который по умолчанию равен ldc.

Scheme переменная: emacs-build-system

Эта переменная экспортируется в (guix build-system emacs). Она реализует процедуру установки, аналогичную системе упаковки самого Emacs (see Packages in The GNU Emacs Manual).

Сначала она создает файл package-autoloads.el, а затем байт-компилирует все файлы Emacs Lisp. В отличие от системы упаковки Emacs, файлы документации Info перемещаются в стандартный каталог документации, а файл dir удаляется. Файлы пакета Elisp устанавливаются непосредственно в share/emacs/site-lisp.

Scheme переменная: font-build-system

Эта переменная экспортируется в (guix build-system font). Она реализует процедуру установки для пакетов шрифтов, в которой upstream предоставляет предварительно скомпилированные файлы TrueType, OpenType и т.д. файлы шрифтов, которые необходимо просто скопировать на место. Она копирует файлы шрифтов в стандартные места выходного каталога.

Scheme переменная: meson-build-system

Эта переменная экспортируется в (guix build-system meson). Она реализует процедуру сборки для пакетов, которые используют Meson в качестве своей системы сборки.

Она добавляет к набору входов как Meson, так и Ninja, и их можно изменить с помощью параметров #:meson и #:ninja. если нужно. По умолчанию Meson - это meson-for-build, что является особенным, потому что он не очищает RUNPATH от двоичных файлов и библиотек при их установке.

Эта система сборки является расширением gnu-build-system, но со следующими фазами, измененными на некоторые специфичные для Meson:

configure

На этапе выполняется meson с флагами, указанными в #:configure-flags. Флаг --buildtype всегда установлен на debugoptimized, если что-то еще не указано в #:build-type.

build

На этапе выполняется ninja для параллельной сборки пакета по умолчанию, но это можно изменить с помощью #:parallel-build?.

check

На этапе выполняется ninja с целью, указанной в #:test-target, по умолчанию это "test".

установка

Фаза выполняется ninja install и не может быть изменен.

Помимо этого, система сборки также добавляет следующие фазы:

fix-runpath

Эта фаза гарантирует, что все двоичные файлы могут найти нужные библиотеки. Она ищет необходимые библиотеки в подкаталогах собираемого пакета и, при необходимости, добавляет их в RUNPATH. Она также удаляет ссылки на библиотеки, оставшиеся от фазы сборки meson-for-build, такие как тестовые зависимости, которые на самом деле не требуются для запуска программы.

glib-or-gtk-wrap

Эта фаза предоставляется glib-or-gtk-build-system и по умолчанию не включена. Ее можно включить с помощью #:glib-or-gtk?.

glib-or-gtk-compile-schemas

Эта фаза предоставляется glib-or-gtk-build-system и по умолчанию не включена. Ее можно включить с помощью #:glib-or-gtk?.

Scheme переменная: linux-module-build-system

linux-module-build-system позволяет создавать модули ядра Linux.

Эта система сборки является расширением gnu-build-system, но со следующими изменениями:

configure

На этой фазе среда настраивается таким образом, чтобы Makefile ядра Linux можно было использовать для сборки внешнего модуля ядра.

build

На этой фазе используется Makefile ядра Linux для сборки внешнего модуля ядра.

установка

На этой фазе используется Makefile ядра Linux для установки внешнего модуля ядра.

Возможно и полезно указать ядро Linux, которое будет использоваться для сборки модуля (в форме arguments пакета с использованием linux-module-build-system используйте ключ #:linux, чтобы указать это).

Scheme переменная: node-build-system

Эта переменная экспортируется в (guix build-system node). Она реализует процедуру сборки, используемую Node.js, которая реализует аппроксимацию команды npm install, за которой следует команда npm test.

Какой пакет Node.js используется для интерпретации команд npm, можно указать с помощью параметра #:node, который по умолчанию равен node.

Наконец, для пакетов, которым не нужно ничего столь же сложного, предоставляется “trivial” система сборки. Она тривиальна в том смысле, что она практически не оказывает поддержки при сборке: она не извлекает никаких неявных входных данных и не имеет понятия о этапах сборки.

Scheme переменная: trivial-build-system

Эта переменная экспортируется (guix build-system trivial).

Эта система сборки требует аргумента #:builder. Этот аргумент должен быть Scheme выражением, которое строит выходные данные пакета—как с build-expression->derivation (see build-expression->derivation).


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.5 Фазы сборки

Почти все системы сборки пакетов реализуют понятие фазы сборки: последовательность действий, которые система сборки выполняет при сборке пакета, что приводит к установке побочных продуктов в store. Заметным исключением является “bare-bones” trivial-build-system (see Системы сборки).

As discussed in the previous section, those build systems provide a standard list of phases. For gnu-build-system, the main build phases are the following:

unpack

Распаковать архив исходных текстов и измените текущий каталог на извлеченное дерево исходных текстов. Если источник на самом деле является каталогом, скопировать его в дерево сборки и войдите в этот каталог.

patch-source-shebangs

Изменить shebang, встречающиеся в исходных файлах, чтобы они ссылались на правильные имена файлов хранилища. Например, это изменяет #!/bin/sh на #!/gnu/store/…-bash-4.3/bin/sh.

configure

Запустить сценарий configure с несколькими параметрами по умолчанию, такими как --prefix=/gnu/store/…, а также параметрами, указанными в #:configure-flags аргументе.

build

Запустить make со списком флагов, указанным с помощью #:make-flags. Если аргумент #:parallel-build? истинен (по умолчанию), выполнить сборку с make -j.

check

Запустить make check или другой target, указанный с помощью #:test-target, если только #:tests? #f пройден. Если аргумент #:parallel-tests? истинен (по умолчанию), запустить make check -j.

установка

Запустить make install с флагами, перечисленными в #:make-flags.

patch-shebangs

Изменить shebangs на установленные исполняемые файлы.

strip

Удалить символы отладки из файлов ELF (если #:strip-binaries? не является ложным), скопировав их в выходные данные debug, если они доступны (see Установка файлов отладки).

Other build systems have similar phases, with some variations. For example, cmake-build-system has same-named phases but its configure phases runs cmake instead of ./configure. Others, such as python-build-system, have a wholly different list of standard phases. All this code runs on the build side: it is evaluated when you actually build the package, in a dedicated build process spawned by the build daemon (see Вызов guix-daemon).

Этапы сборки представлены в виде ассоциативных списков или “alists” (see Association Lists in GNU Guile Reference Manual), где каждый ключ является символом имени фазы, а соответствующее значение - процедурой, которая принимает произвольное количество аргументов. По соглашению эти процедуры получают информацию о сборке в виде ключевых параметров, которые они могут использовать или игнорировать.

Например, вот как (guix build gnu-build-system) определяет %standard-phase, переменную, содержащую список фаз сборки 16:

;; The build phases of 'gnu-build-system'.

(define* (unpack #:key source #:allow-other-keys)
  ;; Extract the source tarball.
  (invoke "tar" "xvf" source))

(define* (configure #:key outputs #:allow-other-keys)
  ;; Run the 'configure' script.  Install to output "out".
  (let ((out (assoc-ref outputs "out")))
    (invoke "./configure"
            (string-append "--prefix=" out))))

(define* (build #:allow-other-keys)
  ;; Compile.
  (invoke "make"))

(define* (check #:key (test-target "check") (tests? #true)
                #:allow-other-keys)
  ;; Run the test suite.
  (if tests?
      (invoke "make" test-target)
      (display "test suite not run\n")))

(define* (install #:allow-other-keys)
  ;; Install files to the prefix 'configure' specified.
  (invoke "make" "install"))

(define %standard-phases
  ;; The list of standard phases (quite a few are omitted
  ;; for brevity).  Each element is a symbol/procedure pair.
  (list (cons 'unpack unpack)
        (cons 'configure configure)
        (cons 'build build)
        (cons 'check check)
        (cons 'install install)))

Это показывает, как %standard-phase определяется как список пар символ/процедура (see Pairs in GNU Guile Reference Manual). Первая пара связывает процедуру unpack с символом unpack—именем; вторая пара аналогичным образом определяет фазу configure и так далее. При сборке пакета, который использует gnu-build-system со списком фаз по умолчанию, эти фазы выполняются последовательно. Вы можете увидеть название каждой фазы, запущенной и завершенной, в журнале сборки пакетов, которые вы собираете.

Теперь посмотрим на сами процедуры. Каждая из них определяется с помощью define*: #:key перечисляет параметры ключевого слова, которые принимает процедура, возможно, со значением по умолчанию, а #:allow-other-keys указывает, что другие параметры ключевого слова являются игнорируется (see Optional Arguments in GNU Guile Reference Manual).

Процедура unpack учитывает параметр source, который система сборки использует для передачи имени файла исходного архива (или checkout контроля версий), и игнорирует другие параметры. Фаза configure касается только параметра output, списка имен выходных пакетов, отображающих имена файлов хранилища (see Пакеты со множественным выходом). Она извлекает имя файла для out, вывода по умолчанию, и передает его ./configure в качестве префикса установки, что означает, что make install в конечном итоге скопирует все файлы в этом каталоге (see configuration and makefile conventions in GNU Coding Standards). build и install игнорируют все свои аргументы. check учитывает аргумент test-target, который указывает имя цели Makefile для запуска тестов; она печатает сообщение и пропускает тесты, если tests? ложно.

Список фаз, используемых для конкретного пакета, можно изменить с помощью параметра #:phase системы сборки. Изменение набора фаз сборки сводится к созданию нового списка фаз на основе списка %standard-phase, описанного выше. Это можно сделать с помощью стандартных процедур списков, таких как alist-delete (see SRFI-1 Association Lists in GNU Guile Reference Manual); однако это удобнее делать с помощью modify-phase (see modify-phases).

Вот пример определения пакета, который удаляет фазу configure из %standard-phase и вставляет новую фазу перед фазой build, которая называется set-prefix-in- makefile:

(define-public example
  (package
    (name "example")
    ;; other fields omitted
    (build-system gnu-build-system)
    (arguments
     '(#:phases (modify-phases %standard-phases
                  (delete 'configure)
                  (add-before 'build 'set-prefix-in-makefile
                    (lambda* (#:key outputs #:allow-other-keys)
                      ;; Modify the makefile so that its
                      ;; 'PREFIX' variable points to "out".
                      (let ((out (assoc-ref outputs "out")))
                        (substitute* "Makefile"
                          (("PREFIX =.*")
                           (string-append "PREFIX = "
                                          out "\n")))
                        #true))))))))

Новая вставляемая фаза записывается как анонимная процедура, представленная с помощью lambda*; она учитывает параметр output, который мы видели ранее. See Утилиты, чтобы узнать больше о помощниках, используемых в этой фазе, и получить больше примеров modify-phase.

Имейте в виду, что фазы сборки - это код, выполняемый во время фактической сборки пакета. Это объясняет, почему приведенное выше выражение modify-phase целиком (оно идет после ' или апострофа): это staged для последующего выполнения. See G-Expressions для объяснения staging кода и задействованных code strata.


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.6 Build Utilities

Как только вы начнете писать нетривиальные определения пакетов (see Описание пакетов) или другие действия сборки (see G-Expressions), вы, скорее всего, начнете искать помощников для действий, подобных оболочке—создание каталогов, рекурсивное копирование и удаление файлов, управление этапами сборки и т.д. Модуль (guix build utils) предоставляет такие служебные процедуры.

Большинство систем сборки загружают (guix build utils) (see Системы сборки). Таким образом, при написании настраиваемых фаз сборки для определений пакетов вы обычно можете предположить, что эти процедуры входят в область действия.

При написании G-выражений вы можете импортировать (guix build utils) на “стороне сборки”, используя with-import-modules, а затем поместить его в область видимости с помощью формы use-modules (see Using Guile Modules in GNU Guile Reference Manual):

(with-imported-modules '((guix build utils))  ;import it
  (computed-file "empty-tree"
                 #~(begin
                     ;; Put it in scope.
                     (use-modules (guix build utils))

                     ;; Happily use its 'mkdir-p' procedure.
                     (mkdir-p (string-append #$output "/a/b/c")))))

Оставшаяся часть этого раздела является справочником по большинству служебных процедур, предоставляемых (guix build utils).

8.6.1 Работа с именами файлов в store

В этом разделе описаны процедуры, относящиеся к именам файлов в store.

Scheme Procedure: %store-directory

Return the directory name of the store.

Scheme Procedure: store-file-name? file

Return true if file is in the store.

Scheme Procedure: strip-store-file-name file

Удалиnm /gnu/store и хэш из file, имени файла в store. Результатом обычно является строка "package-version".

Scheme Procedure: package-name->name+version name

Учитывая name, имя пакета, такое как "foo-0.9.1b", возвращает два значения: "foo" и "0.9.1b". Если часть версии недоступна, возвращаются name и #f. Считается, что первый дефис, за которым следует цифра, обозначает часть версии.

8.6.2 File Types

The procedures below deal with files and file types.

Scheme Procedure: directory-exists? dir

Вернуть #t, если dir существует и является каталогом.

Scheme Procedure: executable-file? file

Вернуть #t, если file существует и исполняемый файл.

Вернуть #t, если file является символической ссылкой (также известной как “символическая ссылка”).

Scheme Procedure: elf-file? file
Scheme Procedure: ar-file? file
Scheme Procedure: gzip-file? file

Вернуть #t, если file является, соответственно, файлом ELF, архивом ar (например, статической библиотекой .a) или файлом gzip.

Scheme Procedure: reset-gzip-timestamp file [#:keep-mtime? #t]

Если file является файлом gzip, сбросить его timestamp (как в случае gzip --no-name) и вернуть истину. В противном случае вернуть #f. Когда keep-mtime? истинна, сохранить время модификации file.

8.6.3 Управление файлами

Следующие процедуры и макросы помогают создавать, изменять и удалять файлы. Они обеспечивают функциональность, сопоставимую с такими обычными утилитами оболочки, как mkdir -p, cp -r, rm -r и sed. Они дополняют обширный, но низкоуровневый интерфейс файловой системы Guile (see POSIX in GNU Guile Reference Manual).

Scheme Syntax: with-directory-excursion directory body

Запустить body с directory в качестве текущего каталога процесса.

По сути, этот макрос изменяет текущий каталог на directory перед вычислением body, используя chdir (see Processes in GNU Guile Reference Manual). Она возвращается в исходный каталог, когда остается динамический extent body, будь то через возврат нормальной процедуры или через нелокальный выход, такой как исключение.

Scheme Procedure: mkdir-p dir

Создать каталог dir и всех его предков.

Scheme Procedure: install-file file directory

Создать каталог, если он не существует, и скопировать туда file под тем же именем.

Scheme Procedure: make-file-writable file

Сделать file доступным для записи его владельцу.

Scheme Procedure: copy-recursively source destination [#:log (current-output-port)] [#:follow-symlinks? #f] [#:keep-mtime? #f]

Скопировать каталог source в destination. Следовать символическим ссылкам, если follow-symlinks? истинна; в противном случае просто сохранить их. Когда keep-mtime? истинна, оставить время изменения файлов в source таким же, как у destination. Записывать подробный вывод в порт log.

Scheme Procedure: delete-file-recursively dir [#:follow-mounts? #f] dir рекурсивно, как rm -rf, без

использования символических ссылок. Также не следовать точкам монтирования, если follow-mounts? не истинна. Сообщать об ошибках, но игнорировать их.

Scheme Syntax: substitute* file ((regexp match-var…) body…) … Заменить

regexp в file строкой, возвращаемой body. body вычисляется с каждой привязкой match-var к соответствующему подвыражению позиционного регулярного выражения. Например:

(substitute* file
  (("hello")
   "good morning\n")
  (("foo([a-z]+)bar(.*)$" all letters end)
   (string-append "baz" letter end)))

Здесь, когда строка file содержит hello, она заменяется на good morning. Каждый раз, когда строка file соответствует второму регулярному выражению, all привязывается к полному совпадению, letters привязано к первому подвыражению, а end привязано к последнему.

Когда одно из match-var - _, никакая переменная не связана с соответствующей подстрокой соответствия.

В качестве альтернативы file может быть списком имен файлов, и в этом случае все они могут быть заменены.

В качестве альтернативы file может быть списком имен файлов, и в этом случае все они могут быть заменены.

8.6.4 File Search

В этом разделе описаны процедуры поиска и фильтрации файлов.

Scheme Procedure: file-name-predicate regexp

Вернуть предикат, который возвращает истину при передаче имени файла, базовое имя которого совпадает с regexp.

Scheme Procedure: find-files dir [pred] [#:stat lstat] [#:directories? #f] [#:fail-on-error? #f] Возвращает

лексикографически отсортированный список файлов в dir, для которых pred возвращает истину. pred передается два аргумента: абсолютное имя файла и его буфер статистики; предикат по умолчанию всегда возвращает истину. pred также может быть регулярным выражением, в этом случае оно эквивалентно (file-name-predicate pred). stat используется для получения информации о файле; использование lstat означает, что символические ссылки не соблюдаются. Если directories? истина, то каталоги также будут включены. Если fail-on-error? истина, генерировать исключение при ошибке.

Вот несколько примеров, в которых мы предполагаем, что текущий каталог является корнем дерева исходников Guix:

;; List all the regular files in the current directory.
(find-files ".")
 ("./.dir-locals.el" "./.gitignore" )

;; List all the .scm files under gnu/services.
(find-files "gnu/services" "\\.scm$")
 ("gnu/services/admin.scm" "gnu/services/audio.scm" )

;; List ar files in the current directory.
(find-files "." (lambda (file stat) (ar-file? file)))
 ("./libformat.a" "./libstore.a" )
Scheme Procedure: which program

Вернуть полное имя файла для program, как в $PATH, или #f, если program не найдена.

8.6.5 Фазы сборки

(guix build utils) также содержит инструменты для управления фазами сборки, которые используются системами сборки (see Системы сборки). Фазы сборки представлены в виде ассоциативных списков или “alists” (see Association Lists in GNU Guile Reference Manual), где каждый ключ представляет собой символ, обозначающий фазу, а связанное значение представляет собой процедуру (see Фазы сборки).

Ядро Guile и модуль (srfi srfi-1) предоставляют инструменты для управления списками. Модуль (guix build utils) дополняет их инструментами, написанными с учетом фаз сборки.

Scheme Syntax: modify-phases phases clause

Изменить phases последовательно в соответствии с каждым clause, которое может иметь одну из следующих форм:

(delete old-phase-name)
(replace old-phase-name new-phase)
(add-before old-phase-name new-phase-name new-phase)
(add-after old-phase-name new-phase-name new-phase)

Где каждая phase-name выше - это выражение, преобразующееся в символ, а new-phase - выражение, преобразующееся в процедуру.

Пример ниже взят из определения пакета grep. Он добавляет фазу для запуска после фазы install, которая называется fix-egrep-and-fgrep. Эта фаза представляет собой процедуру (lambda* обозначает анонимную процедуру), которая принимает аргумент ключевого слова #:output и игнорирует дополнительные аргументы ключевого слова (see Optional Arguments in GNU Guile Reference Manual, for more on lambda* and optional and keyword arguments.) В фазе используется substitute* для изменения установленных сценариев egrep и fgrep, чтобы они ссылались на grep по абсолютному имени файла:

(modify-phases %standard-phases
  (add-after 'install 'fix-egrep-and-fgrep
    ;; Patch 'egrep' and 'fgrep' to execute 'grep' via its
    ;; absolute file name instead of searching for it in $PATH.
    (lambda* (#:key outputs #:allow-other-keys)
      (let* ((out (assoc-ref outputs "out"))
             (bin (string-append out "/bin")))
        (substitute* (list (string-append bin "/egrep")
                           (string-append bin "/fgrep"))
          (("^exec grep")
           (string-append "exec " bin "/grep")))
        #t))))

В приведенном ниже примере фазы изменяются двумя способами: стандартная фаза configure удаляется, предположительно потому, что в пакете нет сценария configure или чего-то подобного, и фаза install по умолчанию заменяется файлом, который вручную копирует устанавливаемые исполняемые файлы:

(modify-phases %standard-phases
  (delete 'configure)      ;no 'configure' script
  (replace 'install
    (lambda* (#:key outputs #:allow-other-keys)
      ;; The package's Makefile doesn't provide an "install"
      ;; rule so do it by ourselves.
      (let ((bin (string-append (assoc-ref outputs "out")
                                "/bin")))
        (install-file "footswitch" bin)
        (install-file "scythe" bin)
        #t))))

Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.7 Хранилище

Концептуально store - это место, где хранятся успешно построенные derivation’ы - по умолчанию /gnu/store. Подкаталоги в store называются store items или иногда store paths. У store есть связанная база данных, которая содержит такую информацию, как store paths, на которые ссылается каждый store path, и список валидных store item’ов—результаты успешных сборок. Эта база данных находится в localstatedir/guix/db, где localstatedir - это каталог состояний, указанный через --localstatedir во время configure, обычно /var.

Демон всегда обращается к store от имени своих клиентов (see Вызов guix-daemon). Чтобы управлять store, клиенты подключаются к демону через сокет домена Unix, отправляют ему запросы и читают результат - это вызовы удаленных процедур или RPC.

Примечание: Пользователи должны никогда напрямую изменять файлы в /gnu/store. Это приведет к несоответствиям и нарушит предположения о неизменности функциональной модели Guix (see Введение).

See guix gc --verify, для получения информации о том, как проверить целостность store и попытаться восстановить его после случайных изменений.

Модуль (guix store) предоставляет процедуры для подключения к демону и выполнения RPC. Они описаны ниже. По умолчанию open-connection и, следовательно, все команды guix подключаются к локальному демону или к URI, указанному в переменной среды GUIX_DAEMON_SOCKET.

Environment Variable: GUIX_DAEMON_SOCKET

Если установлено, значение этой переменной должно быть именем файла или URI, обозначающим конечную точку демона. Когда это имя файла, оно обозначает сокет домена Unix, к которому нужно подключиться. Помимо имен файлов, поддерживаются следующие схемы URI:

file
unix

Это для сокетов домена Unix. file:///var/guix/daemon-socket/socket эквивалентен /var/guix/daemon-socket/socket.

guix

Эти URI обозначают соединения через TCP/IP без шифрования и аутентификации удаленного хоста. В URI необходимо указать имя хоста и, возможно, номер порта (по умолчанию используется порт 44146):

guix://master.guix.example.org:1234

Эта настройка подходит для локальных сетей, таких как кластеры, где только доверенные узлы могут подключаться к демону сборки по адресу master.guix.example.org.

Параметр --listen команды guix-daemon можно использовать для указания ему прослушивать TCP-соединения (see --listen).

ssh

These URIs allow you to connect to a remote daemon over SSH. This feature requires Guile-SSH (see Требования) and a working guile binary in PATH on the destination machine. It supports public key and GSSAPI authentication. A typical URL might look like this:

ssh://charlie@guix.example.org:22

Что касается guix copy, учитываются обычные файлы конфигурации клиента OpenSSH (see Запуск guix copy).

В будущем могут поддерживаться дополнительные схемы URI.

Примечание: Возможность подключения к демонам удаленной сборки считается экспериментальной с 1.3.0. Пожалуйста, свяжитесь с нами, чтобы поделиться любыми проблемами или предложениями, которые могут у вас возникнуть (see Содействие).

Scheme Procedure: open-connection [uri] [#:reserve-space? #t]

Подключится к демону через сокет домена Unix по адресу uri (строка). Когда reserve-space? истинна, указать ему, чтобы он зарезервировал немного дополнительного места в файловой системе, чтобы сборщик мусора мог работать, если диск заполнится. Вернуть объект сервера.

file по умолчанию - %default-socket-path, что является обычным расположением с учетом параметров, переданных в configure.

Scheme Procedure: close-connection server

Закрыть соединение с server.

Scheme Variable: current-build-output-port

Эта переменная привязана к параметру SRFI-39, который относится к порту, на который должны быть записаны журналы сборки и ошибок, отправляемые демоном.

Процедуры, которые заставляют все RPC принимать объект сервера в качестве своего первого аргумента.

Scheme Procedure: valid-path? server path

Возвращать #t, когда path обозначает допустимый элемент хранилища, и #f в противном случае (недопустимый элемент может существовать на диске, но по-прежнему быть недопустимым, например, потому что он является результатом прерывания или неудачной сборки).

Условие &store-protocol-error возникает, если path не имеет префикса в каталоге store (/gnu/store).

Scheme Procedure: add-text-to-store server name text [references]

Добавить text в файл name в store и вернуть его store path. references - это список store path’ы, на которые ссылается конечный store path.

Scheme Procedure: build-derivations store derivations [mode] Собрать derivations, список объектов <derivation>,

имен файлов .drv или пар derivation/output, используя указанный mode(build-mode normal) по умолчанию.

Обратите внимание, что модуль (guix monads) предоставляет как монаду, так и монадические версии вышеупомянутых процедур с целью сделать более удобной работу с кодом, который обращается к store (see Устройство склада).

Этот раздел в настоящее время не завершен.


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.8 Деривации

Действия низкоуровневой сборки и среда, в которой они выполняются, представлены через derivations. Derivation содержит следующую информацию:

Derivation’ы позволяют клиентам демона передавать действия сборки в store. Они существуют в двух формах: как представление в памяти, как на стороне клиента, так и на стороне демона, и в виде файлов в хранилище, имена которых заканчиваются на .drv - эти файлы называются derivation paths. Derivation paths могут быть переданы в процедуру build-derivations для выполнения действий сборки, которые они предписывают (see Хранилище).

Такие операции, как загрузка файлов и проверка версий, для которых заранее известен ожидаемый хэш содержимого, моделируются как fixed-output derivations. В отличие от обычных дериваций, выходные данные деривации с фиксированным выходом не зависят от его входных данных - например, загрузка исходного кода дает тот же результат независимо от метода загрузки и используемых инструментов.

Outputs of derivations—то есть результаты сборки—имеют множество references, в соответствии с указаниями RPC references или команды guix gc --references (see Вызов guix gc). References - это набор run-time зависимостей результатов сборки. References - это подмножество входных данных derivation; это подмножество автоматически вычисляется демоном сборки путем сканирования всех файлов в выходных данных.

Модуль (guix diverations) предоставляет представление derivation’ов в виде Scheme объектов, а также процедуры для создания derivation’ов и других манипуляций с ними. Самым низкоуровневым примитивом для создания derivation’а является процедура derivation:

Scheme Procedure: derivation store name builder args [#:outputs '(\"out\")] [#:hash #f] [#:hash-algo #f] [#:recursive? #f] [#:inputs '()] [#:env-vars '()]  [#:system

(%current-system)] [#:references-graphs #f]  [#:allowed-references #f] [#:disallowed-references #f]  [#:leaked-env-vars #f] [#:local-build? #f]  [#:substitutable? #t] [#:properties ’()] Собрать производную с заданными аргументами и вернуть полученный объект <derivation>.

Когда заданы hash и hash-algo, создается fixed-output derivation - то есть результат, который известен заранее, например, загрузка файла. Кроме того, если recursive? истинна, то этот фиксированный вывод может быть исполняемым файлом или каталогом, а hash должен быть хешем архива, содержащего этот вывод.

Когда links-graphs истинна, данная переменная должна быть списком из пар имя файла и путь к store. В этом случае граф ссылок каждого store path экспортируется в среду сборки в соответствующий файл в простом текстовом формате.

Когда allowed-links истинна, данная переменная должна быть списком store item’ов или выходных данных, на которые может ссылаться выход derivation’а. Аналогично, disallowed-links, если она истинна, данная переменная должна быть списком сущностей, на которые не могут ссылаться выходные данные.

Когда leaked-env-vars истинна, данная переменная должна быть списком строк, обозначающих переменные среды, которым разрешено “просачиваться” из среды демона в среду сборки. Это применимо только к fixed-output derivation’ам, т.е. когда hash истинна. Основное использование - разрешить передачу таких переменных, как http_proxy, derivation’ам, которые загружают файлы.

Когда local-build? истинна, объявить, что производная не является хорошим кандидатом для offload и должна быть собрана локально (see Установка демона разгрузки). Это справедливо для небольших derivation’ов, когда затраты на передачу данных перевешивают выгоды.

Когда substitutable? ложно, объявить, что substitutes derivation’ов не должны использоваться (see Подстановки). Это полезно, например, при создании пакетов, которые фиксируют подробности набора команд центрального процессора.

properties должна быть списком ассоциаций, описывающих “свойства” derivation’а. При выводе они сохраняются как есть, без интерпретации.

Вот пример со shell скриптом в качестве его builder’а, предполагая, что store является открытым соединением с демоном, а bash указывает на исполняемый файл Bash в store:

(use-modules (guix utils)
             (guix store)
             (guix derivations))

(let ((builder   ; add the Bash script to the store
        (add-text-to-store store "my-builder.sh"
                           "echo hello world > $out\n" '())))
  (derivation store "foo"
              bash `("-e" ,builder)
              #:inputs `((,bash) (,builder))
              #:env-vars '(("HOME" . "/homeless"))))
 #<derivation /gnu/store/…-foo.drv => /gnu/store/…-foo>

Как можно догадаться, этот примитив неудобно использовать напрямую. Конечно, лучший подход - писать скрипты сборки на Scheme! Лучше всего для этого написать код сборки как “G-выражение” и передать его в gexp->derivation. Для получения дополнительной информации, see G-Expressions.

Когда-то давно gexp->derivation не существовала, и построение derivation’ов с помощью кода сборки, написанного на Scheme, достигалось с помощью build-expression->derivation, описанной ниже. Эта процедура теперь устарела и заменена более приятным gexp->derivation.

Scheme Procedure: build-expression->derivation store name exp  [#:system (%current-system)] [#:inputs '()] [#:outputs '(\"out\")] [#:hash #f] [#:hash-algo #f]  [#:recursive? #f]

[#:env-vars ’()] [#:modules ’()]  [#:references-graphs #f] [#:allowed-references #f]  [#:disallowed-references #f]  [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f] Возвращает derivation, которая исполняет Scheme выражение exp как builder для derivation’а name. inputs должна быть списком кортежей (name drv-path sub-drv); когда sub-drv опущена, предполагается "out". modules - это список имен модулей Guile из текущего пути поиска, которые будут скопированы в store, скомпилированы и станут доступными в пути загрузки во время выполнения exp—например, ((guix build utils) (guix build gnu-build-system)).

exp выполняется в среде, где %output привязан к списку пар output/path, а где %build-inputs привязан к списку пар строка/output-path сделаными из input. Необязательно, env-vars - это список пар строк, определяющих имя и значение переменных среды, видимых builder’у. Builder завершает работу, передавая результат exp в exit; таким образом, когда exp возвращает #f, сборка считается неудачной.

exp собирается с использованием guile-for-build (derivation). Когда guile-for-build опущена или равна #f, вместо этого используется значение fluid’а %guile-for-build.

См. в процедуре derivation значение references-graphs, allowed-references, disallowed-references, local-build? и substitutable?.

Вот пример single-output derivation’а, которая создает каталог, содержащий один файл:

(let ((builder '(let ((out (assoc-ref %outputs "out")))
                  (mkdir out)    ; create /gnu/store/…-goo
                  (call-with-output-file (string-append out "/test")
                    (lambda (p)
                      (display '(hello guix) p))))))
  (build-expression->derivation store "goo" builder))

 #<derivation /gnu/store/…-goo.drv => …>

Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.9 Устройство склада

Все процедуры, которые работают с store, описанные в предыдущих разделах, принимают открытое соединение с демоном сборки в качестве первого аргумента. Хотя основная модель является функциональной, они либо имеют побочные эффекты, либо зависят от текущего состояния store.

Первое неудобно: соединение с демоном сборки должно поддерживаться во всех этих функциях, что делает невозможным составление функций, которые не принимают этот параметр, с функциями, которые его принимают. Последнее может быть проблематичным: поскольку операции store имеют побочные эффекты и/или зависят от внешнего состояния, они должны быть правильно упорядочены.

Здесь на помощь приходит модуль (guix monads). Этот модуль предоставляет основу для работы с monads и особенно полезную монаду для наших целей - store monad. Монады - это конструкции, которая позволяют две вещи: связывать “контекст” со значениями (в нашем случае контекст - это store) и строить последовательности вычислений (здесь вычисления включают доступ к store). Значения в монаде—значения, которые несут этот дополнительный контекст—называются монадическими значениями; процедуры, возвращающие такие значения, называются монадическими процедурами.

Рассмотрим эту “нормальную” процедуру:

(define (sh-symlink store)
  ;; Return a derivation that symlinks the 'bash' executable.
  (let* ((drv (package-derivation store bash))
         (out (derivation->output-path drv))
         (sh  (string-append out "/bin/bash")))
    (build-expression->derivation store "sh"
                                  `(symlink ,sh %output))))

Используя (guix monads) и (guix gexp), ее можно переписать как монадическую функцию:

(define (sh-symlink)
  ;; Same, but return a monadic value.
  (mlet %store-monad ((drv (package->derivation bash)))
    (gexp->derivation "sh"
                      #~(symlink (string-append #$drv "/bin/bash")
                                 #$output))))

Во второй версии следует отметить несколько моментов: параметр store теперь является неявным и является “threaded” в вызовах package->derivation и gexp->derivation монадические процедуры, а монадическим значением, возвращаемым package->derivation, является bound с использованием mlet вместо простого let.

Оказывается, вызов package->derivation можно даже опустить, поскольку она будет выполняться неявно, как мы увидим позже (see G-Expressions):

(define (sh-symlink)
  (gexp->derivation "sh"
                    #~(symlink (string-append #$bash "/bin/bash")
                               #$output)))

Вызов монадического sh-symlink ни на что не влияет. Как кто-то однажды сказал: “Вы выходите из монады, как вы выходите из горящего здания: by running”. Итак, чтобы выйти из монады и получить желаемый эффект, нужно использовать run-with-store:

(run-with-store (open-connection) (sh-symlink))
 /gnu/store/...-sh-symlink

Обратите внимание, что модуль (guix monad-repl) расширяет Guile REPL новыми “метакомандами”, чтобы упростить работу с монадическими процедурами: run-in-store и Enter-store-monad. Первая используется для “run” одного монадического значения через store:

scheme@(guile-user)> ,run-in-store (package->derivation hello)
$1 = #<derivation /gnu/store/…-hello-2.9.drv => …>

Последний входит в рекурсивный REPL, где все возвращаемые значения автоматически проходят через хранилище:

scheme@(guile-user)> ,enter-store-monad
store-monad@(guile-user) [1]> (package->derivation hello)
$2 = #<derivation /gnu/store/…-hello-2.9.drv => …>
store-monad@(guile-user) [1]> (text-file "foo" "Hello!")
$3 = "/gnu/store/…-foo"
store-monad@(guile-user) [1]> ,q
scheme@(guile-user)>

Обратите внимание, что немонадические значения не могут быть возвращены в REPL store-monad.

Основные синтаксические формы для работы с монадами в целом предоставляются модулем (guix monads) и описаны ниже.

Scheme Syntax: with-monad monad body ...

Evaluate any >>= or return forms in body as being in monad.

Scheme Syntax: return val

Return a monadic value that encapsulates val.

Scheme Syntax: >>= mval mproc ...

Bind monadic value mval, passing its “contents” to monadic procedures mproc17. There can be one mproc or several of them, as in this example:

(run-with-state
    (with-monad %state-monad
      (>>= (return 1)
           (lambda (x) (return (+ 1 x)))
           (lambda (x) (return (* 2 x)))))
  'some-state)

 4
 some-state
Scheme Syntax: mlet monad ((var mval) ...) body ...
Scheme Syntax: mlet* monad ((var mval) ...) body ... Bind the variables var to the monadic values

mval in body, which is a sequence of expressions. As with the bind operator, this can be thought of as “unpacking” the raw, non-monadic value “contained” in mval and making var refer to that raw, non-monadic value within the scope of the body. The form (var -> val) binds var to the “normal” value val, as per let. The binding operations occur in sequence from left to right. The last expression of body must be a monadic expression, and its result will become the result of the mlet or mlet* when run in the monad.

mlet* is to mlet what let* is to let (see Local Bindings in GNU Guile Reference Manual).

Scheme System: mbegin monad mexp ...

Bind mexp and the following monadic expressions in sequence, returning the result of the last expression. Every expression in the sequence must be a monadic expression.

This is akin to mlet, except that the return values of the monadic expressions are ignored. In that sense, it is analogous to begin, but applied to monadic expressions.

Scheme System: mwhen condition mexp0 mexp* ...

When condition is true, evaluate the sequence of monadic expressions mexp0..mexp* as in an mbegin. When condition is false, return *unspecified* in the current monad. Every expression in the sequence must be a monadic expression.

Scheme System: munless condition mexp0 mexp* ...

When condition is false, evaluate the sequence of monadic expressions mexp0..mexp* as in an mbegin. When condition is true, return *unspecified* in the current monad. Every expression in the sequence must be a monadic expression.

The (guix monads) module provides the state monad, which allows an additional value—the state—to be threaded through monadic procedure calls.

Scheme Variable: %state-monad

The state monad. Procedures in the state monad can access and change the state that is threaded.

Consider the example below. The square procedure returns a value in the state monad. It returns the square of its argument, but also increments the current state value:

(define (square x)
  (mlet %state-monad ((count (current-state)))
    (mbegin %state-monad
      (set-current-state (+ 1 count))
      (return (* x x)))))

(run-with-state (sequence %state-monad (map square (iota 3))) 0)
 (0 1 4)
 3

When “run” through %state-monad, we obtain that additional state value, which is the number of square calls.

Monadic Procedure: current-state

Вернуть текущее состояние в виде монадического значения.

Monadic Procedure: set-current-state value

Set the current state to value and return the previous state as a monadic value.

Monadic Procedure: state-push value

Push value to the current state, which is assumed to be a list, and return the previous state as a monadic value.

Monadic Procedure: state-pop

Pop a value from the current state and return it as a monadic value. The state is assumed to be a list.

Scheme Procedure: run-with-state mval [state]

Run monadic value mval starting with state as the initial state. Return two values: the resulting value, and the resulting state.

The main interface to the store monad, provided by the (guix store) module, is as follows.

Scheme Variable: %store-monad

The store monad—an alias for %state-monad.

Values in the store monad encapsulate accesses to the store. When its effect is needed, a value of the store monad must be “evaluated” by passing it to the run-with-store procedure (see below).

Scheme Procedure: run-with-store store mval [#:guile-for-build] [#:system (%current-system)]

Run mval, a monadic value in the store monad, in store, an open store connection.

Monadic Procedure: text-file name text [references]

Return as a monadic value the absolute file name in the store of the file containing text, a string. references is a list of store items that the resulting text file refers to; it defaults to the empty list.

Monadic Procedure: binary-file name data [references]

Return as a monadic value the absolute file name in the store of the file containing data, a bytevector. references is a list of store items that the resulting binary file refers to; it defaults to the empty list.

Monadic Procedure: interned-file file [name] [#:recursive? #t] [#:select? (const #t)] Return the name of file once

interned in the store. Use name as its store name, or the basename of file if name is omitted.

When recursive? is true, the contents of file are added recursively; if file designates a flat file and recursive? is true, its contents are added, and its permission bits are kept.

When recursive? is true, call (select? file stat) for each directory entry, where file is the entry’s absolute file name and stat is the result of lstat; exclude entries for which select? does not return true.

The example below adds a file to the store, under two different names:

(run-with-store (open-connection)
  (mlet %store-monad ((a (interned-file "README"))
                      (b (interned-file "README" "LEGU-MIN")))
    (return (list a b))))

 ("/gnu/store/rwm…-README" "/gnu/store/44i…-LEGU-MIN")

The (guix packages) module exports the following package-related monadic procedures:

Monadic Procedure: package-file package [file] [#:system (%current-system)] [#:target #f]  [#:output "out"] Return as a

monadic value in the absolute file name of file within the output directory of package. When file is omitted, return the name of the output directory of package. When target is true, use it as a cross-compilation target triplet.

Note that this procedure does not build package. Thus, the result might or might not designate an existing file. We recommend not using this procedure unless you know what you are doing.

Monadic Procedure: package->derivation package [system]
Monadic Procedure: package->cross-derivation package target [system] Monadic version of package-derivation and

package-cross-derivation (see Описание пакетов).


Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

8.10 G-Expressions

So we have “derivations”, which represent a sequence of build actions to be performed to produce an item in the store (see Деривации). These build actions are performed when asking the daemon to actually build the derivations; they are run by the daemon in a container (see Вызов guix-daemon).

It should come as no surprise that we like to write these build actions in Scheme. When we do that, we end up with two strata of Scheme code18: the “host code”—code that defines packages, talks to the daemon, etc.—and the “build code”—code that actually performs build actions, such as making directories, invoking make, and so on (see Фазы сборки).

To describe a derivation and its build actions, one typically needs to embed build code inside host code. It boils down to manipulating build code as data, and the homoiconicity of Scheme—code has a direct representation as data—comes in handy for that. But we need more than the normal quasiquote mechanism in Scheme to construct build expressions.

The (guix gexp) module implements G-expressions, a form of S-expressions adapted to build expressions. G-expressions, or gexps, consist essentially of three syntactic forms: gexp, ungexp, and ungexp-splicing (or simply: #~, #$, and #$@), which are comparable to quasiquote, unquote, and unquote-splicing, respectively (see quasiquote in GNU Guile Reference Manual). However, there are major differences:

This mechanism is not limited to package and derivation objects: compilers able to “lower” other high-level objects to derivations or files in the store can be defined, such that these objects can also be inserted into gexps. For example, a useful type of high-level objects that can be inserted in a gexp is “file-like objects”, which make it easy to add files to the store and to refer to them in derivations and such (see local-file and plain-file below).

To illustrate the idea, here is an example of a gexp:

(define build-exp
  #~(begin
      (mkdir #$output)
      (chdir #$output)
      (symlink (string-append #$coreutils "/bin/ls")
               "list-files")))

This gexp can be passed to gexp->derivation; we obtain a derivation that builds a directory containing exactly one symlink to /gnu/store/…-coreutils-8.22/bin/ls:

(gexp->derivation "the-thing" build-exp)

As one would expect, the "/gnu/store/…-coreutils-8.22" string is substituted to the reference to the coreutils package in the actual build code, and coreutils is automatically made an input to the derivation. Likewise, #$output (equivalent to (ungexp output)) is replaced by a string containing the directory name of the output of the derivation.

In a cross-compilation context, it is useful to distinguish between references to the native build of a package—that can run on the host—versus references to cross builds of a package. To that end, the #+ plays the same role as #$, but is a reference to a native package build:

(gexp->derivation "vi"
   #~(begin
       (mkdir #$output)
       (mkdir (string-append #$output "/bin"))
       (system* (string-append #+coreutils "/bin/ln")
                "-s"
                (string-append #$emacs "/bin/emacs")
                (string-append #$output "/bin/vi")))
   #:target "aarch64-linux-gnu")

In the example above, the native build of coreutils is used, so that ln can actually run on the host; but then the cross-compiled build of emacs is referenced.

Another gexp feature is imported modules: sometimes you want to be able to use certain Guile modules from the “host environment” in the gexp, so those modules should be imported in the “build environment”. The with-imported-modules form allows you to express that:

(let ((build (with-imported-modules '((guix build utils))
               #~(begin
                   (use-modules (guix build utils))
                   (mkdir-p (string-append #$output "/bin"))))))
  (gexp->derivation "empty-dir"
                    #~(begin
                        #$build
                        (display "success!\n")
                        #t)))

In this example, the (guix build utils) module is automatically pulled into the isolated build environment of our gexp, such that (use-modules (guix build utils)) works as expected.

Usually you want the closure of the module to be imported—i.e., the module itself and all the modules it depends on—rather than just the module; failing to do that, attempts to use the module will fail because of missing dependent modules. The source-module-closure procedure computes the closure of a module by looking at its source file headers, which comes in handy in this case:

(use-modules (guix modules))   ;for 'source-module-closure'

(with-imported-modules (source-module-closure
                         '((guix build utils)
                           (gnu build vm)))
  (gexp->derivation "something-with-vms"
                    #~(begin
                        (use-modules (guix build utils)
                                     (gnu build vm))
                        )))

In the same vein, sometimes you want to import not just pure-Scheme modules, but also “extensions” such as Guile bindings to C libraries or other “full-blown” packages. Say you need the guile-json package available on the build side, here’s how you would do it:

(use-modules (gnu packages guile))  ;for 'guile-json'

(with-extensions (list guile-json)
  (gexp->derivation "something-with-json"
                    #~(begin
                        (use-modules (json))
                        )))

The syntactic form to construct gexps is summarized below.

Scheme Syntax: #~exp
Scheme Syntax: (gexp exp)

Return a G-expression containing exp. exp may contain one or more of the following forms:

#$obj
(ungexp obj)

Introduce a reference to obj. obj may have one of the supported types, for example a package or a derivation, in which case the ungexp form is replaced by its output file name—e.g., "/gnu/store/…-coreutils-8.22.

If obj is a list, it is traversed and references to supported objects are substituted similarly.

If obj is another gexp, its contents are inserted and its dependencies are added to those of the containing gexp.

If obj is another kind of object, it is inserted as is.

#$obj:output
(ungexp obj output)

This is like the form above, but referring explicitly to the output of obj—this is useful when obj produces multiple outputs (see Пакеты со множественным выходом).

#+obj
#+obj:output
(ungexp-native obj)
(ungexp-native obj output)

Same as ungexp, but produces a reference to the native build of obj when used in a cross compilation context.

#$output[:output]
(ungexp output [output])

Insert a reference to derivation output output, or to the main output when output is omitted.

This only makes sense for gexps passed to gexp->derivation.

#$@lst
(ungexp-splicing lst)

Like the above, but splices the contents of lst inside the containing list.

#+@lst
(ungexp-native-splicing lst)

Like the above, but refers to native builds of the objects listed in lst.

G-expressions created by gexp or #~ are run-time objects of the gexp? type (see below).

Scheme Syntax: with-imported-modules modules body

Mark the gexps defined in body… as requiring modules in their execution environment.

Each item in modules can be the name of a module, such as (guix build utils), or it can be a module name, followed by an arrow, followed by a file-like object:

`((guix build utils)
  (guix gcrypt)
  ((guix config) => ,(scheme-file "config.scm"
                                  #~(define-module ))))

In the example above, the first two modules are taken from the search path, and the last one is created from the given file-like object.

This form has lexical scope: it has an effect on the gexps directly defined in body…, but not on those defined, say, in procedures called from body….

Scheme Syntax: with-extensions extensions body

Mark the gexps defined in body… as requiring extensions in their build and execution environment. extensions is typically a list of package objects such as those defined in the (gnu packages guile) module.

Concretely, the packages listed in extensions are added to the load path while compiling imported modules in body…; they are also added to the load path of the gexp returned by body….

Scheme Procedure: gexp? obj

Return #t if obj is a G-expression.

G-expressions are meant to be written to disk, either as code building some derivation, or as plain files in the store. The monadic procedures below allow you to do that (see Устройство склада, for more information about monads).

Monadic Procedure: gexp->derivation name exp [#:system (%current-system)] [#:target #f] [#:graft? #t]  [#:hash #f]

[#:hash-algo #f]  [#:recursive? #f] [#:env-vars ’()] [#:modules ’()]  [#:module-path %load-path]  [#:effective-version "2.2"]  [#:references-graphs #f] [#:allowed-references #f]  [#:disallowed-references #f]  [#:leaked-env-vars #f]  [#:script-name (string-append name "-builder")]  [#:deprecation-warnings #f]  [#:local-build? #f] [#:substitutable? #t]  [#:properties ’()] [#:guile-for-build #f] Return a derivation name that runs exp (a gexp) with guile-for-build (a derivation) on system; exp is stored in a file called script-name. When target is true, it is used as the cross-compilation target triplet for packages referred to by exp.

modules is deprecated in favor of with-imported-modules. Its meaning is to make modules available in the evaluation context of exp; modules is a list of names of Guile modules searched in module-path to be copied in the store, compiled, and made available in the load path during the execution of exp—e.g., ((guix build utils) (guix build gnu-build-system)).

effective-version determines the string to use when adding extensions of exp (see with-extensions) to the search path—e.g., "2.2".

graft? determines whether packages referred to by exp should be grafted when applicable.

When references-graphs is true, it must be a list of tuples of one of the following forms:

(file-name package)
(file-name package output)
(file-name derivation)
(file-name derivation output)
(file-name store-item)

The right-hand-side of each element of references-graphs is automatically made an input of the build process of exp. In the build environment, each file-name contains the reference graph of the corresponding item, in a simple text format.

allowed-references must be either #f or a list of output names and packages. In the latter case, the list denotes store items that the result is allowed to refer to. Any reference to another store item will lead to a build error. Similarly for disallowed-references, which can list items that must not be referenced by the outputs.

deprecation-warnings determines whether to show deprecation warnings while compiling modules. It can be #f, #t, or 'detailed.

The other arguments are as for derivation (see Деривации).

The local-file, plain-file, computed-file, program-file, and scheme-file procedures below return file-like objects. That is, when unquoted in a G-expression, these objects lead to a file in the store. Consider this G-expression:

#~(system* #$(file-append glibc "/sbin/nscd") "-f"
           #$(local-file "/tmp/my-nscd.conf"))

The effect here is to “intern” /tmp/my-nscd.conf by copying it to the store. Once expanded, for instance via gexp->derivation, the G-expression refers to that copy under /gnu/store; thus, modifying or removing the file in /tmp does not have any effect on what the G-expression does. plain-file can be used similarly; it differs in that the file content is directly passed as a string.

Scheme Procedure: local-file file [name] [#:recursive? #f] [#:select? (const #t)] Return an object representing local

file file to add to the store; this object can be used in a gexp. If file is a literal string denoting a relative file name, it is looked up relative to the source file where it appears; if file is not a literal string, it is looked up relative to the current working directory at run time. file will be added to the store under name–by default the base name of file.

When recursive? is true, the contents of file are added recursively; if file designates a flat file and recursive? is true, its contents are added, and its permission bits are kept.

When recursive? is true, call (select? file stat) for each directory entry, where file is the entry’s absolute file name and stat is the result of lstat; exclude entries for which select? does not return true.

This is the declarative counterpart of the interned-file monadic procedure (see interned-file).

Scheme Procedure: plain-file name content

Return an object representing a text file called name with the given content (a string or a bytevector) to be added to the store.

This is the declarative counterpart of text-file.

Scheme Procedure: computed-file name gexp [#:local-build? #t] [#:options '()] Return an object representing the store

item name, a file or directory computed by gexp. When local-build? is true (the default), the derivation is built locally. options is a list of additional arguments to pass to gexp->derivation.

This is the declarative counterpart of gexp->derivation.

Monadic Procedure: gexp->script name exp [#:guile (default-guile)] [#:module-path %load-path]  [#:system

(%current-system)] [#:target #f] Return an executable script name that runs exp using guile, with exp’s imported modules in its search path. Look up exp’s modules in module-path.

The example below builds a script that simply invokes the ls command:

(use-modules (guix gexp) (gnu packages base))

(gexp->script "list-files"
              #~(execl #$(file-append coreutils "/bin/ls")
                       "ls"))

When “running” it through the store (see run-with-store), we obtain a derivation that produces an executable file /gnu/store/…-list-files along these lines:

#!/gnu/store/…-guile-2.0.11/bin/guile -ds
!#
(execl "/gnu/store/…-coreutils-8.22"/bin/ls" "ls")
Scheme Procedure: program-file name exp [#:guile #f] [#:module-path %load-path] Return an object representing the

executable store item name that runs gexp. guile is the Guile package used to execute that script. Imported modules of gexp are looked up in module-path.

This is the declarative counterpart of gexp->script.

Monadic Procedure: gexp->file name exp [#:set-load-path? #t] [#:module-path %load-path]  [#:splice? #f]  [#:guile

(default-guile)] Return a derivation that builds a file name containing exp. When splice? is true, exp is considered to be a list of expressions that will be spliced in the resulting file.

When set-load-path? is true, emit code in the resulting file to set %load-path and %load-compiled-path to honor exp’s imported modules. Look up exp’s modules in module-path.

The resulting file holds references to all the dependencies of exp or a subset thereof.

Scheme Procedure: scheme-file name exp [#:splice? #f] [#:set-load-path? #t] Возвращает объект, представляющий

Scheme файл file name содержащий exp.

This is the declarative counterpart of gexp->file.

Monadic Procedure: text-file* name text

Return as a monadic value a derivation that builds a text file containing all of text. text may list, in addition to strings, objects of any type that can be used in a gexp: packages, derivations, local file objects, etc. The resulting store file holds references to all these.

This variant should be preferred over text-file anytime the file to create will reference items from the store. This is typically the case when building a configuration file that embeds store file names, like this:

(define (profile.sh)
  ;; Return the name of a shell script in the store that
  ;; initializes the 'PATH' environment variable.
  (text-file* "profile.sh"
              "export PATH=" coreutils "/bin:"
              grep "/bin:" sed "/bin\n"))

In this example, the resulting /gnu/store/…-profile.sh file will reference coreutils, grep, and sed, thereby preventing them from being garbage-collected during its lifetime.

Scheme Procedure: mixed-text-file name text

Return an object representing store file name containing text. text is a sequence of strings and file-like objects, as in:

(mixed-text-file "profile"
                 "export PATH=" coreutils "/bin:" grep "/bin")

Это декларативный аналог text-file*.

Scheme Procedure: file-union name files

Return a <computed-file> that builds a directory containing all of files. Each item in files must be a two-element list where the first element is the file name to use in the new directory, and the second element is a gexp denoting the target file. Here’s an example:

(file-union "etc"
            `(("hosts" ,(plain-file "hosts"
                                    "127.0.0.1 localhost"))
              (\"bashrc\" ,(plain-file "bashrc"
                                     "alias ls='ls --color=auto'"))))

This yields an etc directory containing these two files.

Scheme Procedure: directory-union name things

Return a directory that is the union of things, where things is a list of file-like objects denoting directories. For example:

(directory-union "guile+emacs" (list guile emacs))

yields a directory that is the union of the guile and emacs packages.

Scheme Procedure: file-append obj suffix

Return a file-like object that expands to the concatenation of obj and suffix, where obj is a lowerable object and each suffix is a string.

В качестве примера рассмотрим этот gexp:

(gexp->script "run-uname"
              #~(system* #$(file-append coreutils
                                        "/bin/uname")))

Такого же эффекта можно добиться с помощью:

(gexp->script "run-uname"
              #~(system* (string-append #$coreutils
                                        "/bin/uname")))

There is one difference though: in the file-append case, the resulting script contains the absolute file name as a string, whereas in the second case, the resulting script contains a (string-append …) expression to construct the file name at run time.

Scheme Syntax: let-system system body
Scheme Syntax: let-system (system target) body

Привязать system к текущей целевой системе—например, \"x86_64-linux\"—в body.

In the second case, additionally bind target to the current cross-compilation target—a GNU triplet such as "arm-linux-gnueabihf"—or #f if we are not cross-compiling.

let-system is useful in the occasional case where the object spliced into the gexp depends on the target system, as in this example:

#~(system*
   #+(let-system system
       (cond ((string-prefix? "armhf-" system)
              (file-append qemu "/bin/qemu-system-arm"))
             ((string-prefix? "x86_64-" system)
              (file-append qemu "/bin/qemu-system-x86_64"))
             (else
              (error "dunno!"))))
   "-net" "user" #$image)
Scheme Syntax: with-parameters ((parameter value) …) exp

This macro is similar to the parameterize form for dynamically-bound parameters (see Parameters in GNU Guile Reference Manual). The key difference is that it takes effect when the file-like object returned by exp is lowered to a derivation or store item.

A typical use of with-parameters is to force the system in effect for a given object:

(with-parameters ((%current-system "i686-linux"))
  coreutils)

The example above returns an object that corresponds to the i686 build of Coreutils, regardless of the current value of %current-system.

Of course, in addition to gexps embedded in “host” code, there are also modules containing build tools. To make it clear that they are meant to be used in the build stratum, these modules are kept in the (guix build …) name space.

Internally, high-level objects are lowered, using their compiler, to either derivations or store items. For instance, lowering a package yields a derivation, and lowering a plain-file yields a store item. This is achieved using the lower-object monadic procedure.

Monadic Procedure: lower-object obj [system] [#:target #f] Return as a value in %store-monad the derivation or

store item corresponding to obj for system, cross-compiling for target if target is true. obj must be an object that has an associated gexp compiler, such as a <package>.


Previous: , Up: Программный интерфейс   [Contents][Index]

8.11 Вызов guix repl

The guix repl command makes it easier to program Guix in Guile by launching a Guile read-eval-print loop (REPL) for interactive programming (see Using Guile Interactively in GNU Guile Reference Manual), or by running Guile scripts (see Running Guile Scripts in GNU Guile Reference Manual). Compared to just launching the guile command, guix repl guarantees that all the Guix modules and all its dependencies are available in the search path.

Основной синтаксис:

guix repl options [file args]

When a file argument is provided, file is executed as a Guile scripts:

guix repl my-script.scm

To pass arguments to the script, use -- to prevent them from being interpreted as arguments to guix repl itself:

guix repl -- my-script.scm --input=foo.txt

To make a script executable directly from the shell, using the guix executable that is on the user’s search path, add the following two lines at the top of the script:

#!/usr/bin/env -S guix repl --
!#

Without a file name argument, a Guile REPL is started:

$ guix repl
scheme@(guile-user)> ,use (gnu packages base)
scheme@(guile-user)> coreutils
$1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

In addition, guix repl implements a simple machine-readable REPL protocol for use by (guix inferior), a facility to interact with inferiors, separate processes running a potentially different revision of Guix.

The available options are as follows:

--type=type
-t type

Start a REPL of the given TYPE, which can be one of the following:

guile

This is default, and it spawns a standard full-featured Guile REPL.

компьютер

Spawn a REPL that uses the machine-readable protocol. This is the protocol that the (guix inferior) module speaks.

--listen=endpoint

By default, guix repl reads from standard input and writes to standard output. When this option is passed, it will instead listen for connections on endpoint. Here are examples of valid options:

--listen=tcp:37146

Accept connections on localhost on port 37146.

--listen=unix:/tmp/socket

Accept connections on the Unix-domain socket /tmp/socket.

--load-path=directory
-L directory

Add directory to the front of the package module search path (see Пакетные модули).

This allows users to define their own packages and make them visible to the script or REPL.

-q

Inhibit loading of the ~/.guile file. By default, that configuration file is loaded when spawning a guile REPL.


Next: , Previous: , Up: Top   [Contents][Index]

9 Утилиты

В этом разделе описаны утилиты командной строки Guix. Некоторые из них в первую очередь нацелены на разработчиков и пользователей, которые пишут новые определения пакетов, в то время как другие полезны в целом. Они удобно дополняют программный интерфейс Scheme в Guix.


Next: , Up: Утилиты   [Contents][Index]

9.1 Запуск guix build

Команда guix build собирает пакеты или производные и их зависимости и выводит полученные пути в хранилище (store paths). Обратите внимание, что она не изменяет профиль пользователя—это задача команды guix package (see Вызов guix package). Таким образом, это в основном полезно для разработчиков дистрибутива.

Основной синтаксис:

guix build options package-or-derivation

В качестве примера следующая команда собирает последние версии Emacs и Guile, отображает их логи и, наконец, отображает полученные директории:

guix build emacs guile

Аналогичным образом следующая команда собирает все доступные пакеты:

guix build --quiet --keep-going \
  $(guix package -A | cut -f1,2 --output-delimiter=@)

package-or-derivation может быть именем пакета, найденного в дистрибутиве программного обеспечения, например coreutils или coreutils@8.20, или производным, например /gnu/store/…-coreutils-8.19.drv. В первом случае пакет с соответствующим именем (и, возможно, версией) ищется среди модулей дистрибутива GNU (see Пакетные модули).

В качестве альтернативы можно использовать параметр --expression, чтобы указать выражение на языке Scheme, оценивающее пакет; это полезно, когда требуется устранение неоднозначности между несколькими пакетами с одинаковыми именами или вариантами пакетов.

Может быть ноль или больше options. Доступные параметры описаны в подразделах ниже.


Next: , Up: Запуск guix build   [Contents][Index]

9.1.1 Стандартные параметры сборки

Ряд параметров, управляющих процессом сборки, является общим для guix build и других команд, которые могут порождать сборки, например guix package или guix archive. Это следующие:

--load-path=directory
-L directory

Add directory to the front of the package module search path (see Пакетные модули).

Это позволяет пользователям определять свои собственные пакеты и делать их видимыми для инструментов командной строки.

--keep-failed
-K

Сохраните дерево сборки неудачных попыток сборки. Таким образом, в случае сбоя сборки ее дерево сборки сохраняется в /tmp, в каталоге, имя которого отображается в конце журнала сборки. Это полезно при отладке проблем сборки. See Отладка ошибок сборки, советы и рекомендации по отладке проблем сборки.

Этот параметр предполагает --no-offload и не действует при подключении к удалённому демону с URI guix:// (see the GUIX_DAEMON_SOCKET.

--keep-going
-k

Продолжайте, когда некоторые из производных не удается построить; возвращайтесь только после того, как все сборки будут завершены или не пройдены.

Поведение по умолчанию—остановка, как только одна из указанных производных не удалась.

--dry-run
-n

Не собирайте производные.

--fallback

Если замена предварительно созданного двоичного файла не удалась, процесс возвращается к сборке пакетов локально (see Ошибки при подстановке).

--substitute-urls=urls

Рассмотрим urls разделенный пробелами список URL-адресов источников замещений, заменяющий список URL-адресов по умолчанию guix-daemon (see guix-daemon URLs).

Это означает, что заменители могут быть загружены с urls, при условии, что они подписаны ключом, авторизованным системным администратором (see Подстановки).

Когда urls является пустой строкой—замены фактически отключены.

--no-substitutes

Не использовать подстановки для сборок. Это означает — собирать элементы локально вместо того, чтобы скачивать собранные бинарники (see Подстановки).

--no-grafts

Не “прививайте” (graft) пакеты. На практике это означает, что обновления пакетов, доступные в виде прививок, не применяются. Ознакомьтесь с See Обновления безопасности, чтобы узнать больше о прививках (grafts).

--rounds=n

Соберите каждое производное n раз подряд и вызовите появление ошибки, если последовательные результаты построения не будут побитно идентичны.

Это полезный способ обнаружения недетерминированных процессов сборки. Недетерминированные процессы сборки представляют собой проблему, потому что они делают практически невозможным для пользователей verify подлинность сторонних двоичных файлов. Обратитесь к See Запуск guix challenge, чтобы узнать больше.

При использовании вместе с --keep-failed различные результаты сохраняются на складе под /gnu/store/…-check. Это делает возможным просмотр различий между двумя результатами.

--no-offload

Do not use offload builds to other machines (see Установка демона разгрузки). That is, always build things locally instead of offloading builds to remote machines.

--max-silent-time=seconds

Когда процесс сборки или подстановки молчит более seconds секунд, завершить его и отчитаться об ошибке сборки.

По умолчанию настройки демона соблюдаются (see --max-silent-time).

--timeout=seconds

Точно так же, когда процесс сборки или подстановки длится более seconds, завершить его и отчитаться об ошибке сборки.

By default, the daemon’s setting is honored (see --timeout).

-v level
--verbosity=level

Use the given verbosity level, an integer. Choosing 0 means that no output is produced, 1 is for quiet output; 2 is similar to 1 but it additionally displays download URLs; 3 shows all the build log output on standard error.

--cores=n
-c n

Разрешить использование до n ядер ЦП для сборки. Специальное значение 0 означает использование максимально доступного количества ядер ЦП.

--max-jobs=n
-M n

Разрешить не более n сборок параллельно. Обратитесь к See --max-jobs для получения подробной информации об этой опции и аналогичной опции guix-daemon.

--debug=level

Создавать отладочные данные, поступающие от демона сборки. level должен быть целым числом от 0 до 5; чем выше, тем подробнее вывод. Уровнь 4 или выше может быть полезен при отладке проблемы с установкой демона сборки.

За кулисами guix build, по сути, является интерфейсом к процедуре package-diveration модуля (guix packages) и к процедуре build-diverations модуля (guix derivations) модуль.

Помимо параметров, явно переданных в командной строке, guix build и другие команды guix, поддерживающие сборку, учитывают переменную среды GUIX_BUILD_OPTIONS.

Environment Variable: GUIX_BUILD_OPTIONS

Пользователи могут определить эту переменную для списка параметров командной строки, которые будут автоматически использоваться guix build и другими командами guix, которые могут выполнять сборки, как в примере ниже:

$ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

Эти параметры анализируются независимо, а результат добавляется к проанализированным параметрам командной строки.


Next: , Previous: , Up: Запуск guix build   [Contents][Index]

9.1.2 Параметры преобразования пакета

Другой набор параметров командной строки, поддерживаемых guix build и guix package это package transformation options. Это параметры, которые позволяют определять package variants—например, пакеты, созданные из другого исходного кода. Это удобный способ создавать индивидуальные пакеты на лету без необходимости вводить определения вариантов пакета (see Описание пакетов).

Параметры преобразования пакета сохраняются при обновлении: guix upgrade пытается применить параметры преобразования, которые изначально использовались при создании профиля, к обновленным пакетам.

Доступные варианты перечислены ниже. Большинство команд поддерживают их, а также поддерживают параметр --help-transform, в котором перечислены все доступные параметры и их крткое описание (эти параметры не показаны в выводе --help для краткости).

--with-source=source
--with-source=package=source
--with-source=package@version=source

Используйте source в качестве источника package и version в качестве номера версии. source должен быть именем файла или URL-адресом, как для guix download (see Запуск guix download).

When package is omitted, it is taken to be the package name specified on the command line that matches the base of source—e.g., if source is /src/guile-2.0.10.tar.gz, the corresponding package is guile.

Likewise, when version is omitted, the version string is inferred from source; in the previous example, it is 2.0.10.

This option allows users to try out versions of packages other than the one provided by the distribution. The example below downloads ed-1.7.tar.gz from a GNU mirror and uses that as the source for the ed package:

guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

As a developer, --with-source makes it easy to test release candidates:

guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

… or to build from a checkout in a pristine environment:

$ git clone git://git.sv.gnu.org/guix.git
$ guix build guix --with-source=guix@1.0=./guix
--with-input=package=replacement

Replace dependency on package by a dependency on replacement. package must be a package name, and replacement must be a package specification such as guile or guile@1.8.

For instance, the following command builds Guix, but replaces its dependency on the current stable version of Guile with a dependency on the legacy version of Guile, guile@2.0:

guix build --with-input=guile=guile@2.0 guix

This is a recursive, deep replacement. So in this example, both guix and its dependency guile-json (which also depends on guile) get rebuilt against guile@2.0.

This is implemented using the package-input-rewriting Scheme procedure (see package-input-rewriting).

--with-graft=package=replacement

This is similar to --with-input but with an important difference: instead of rebuilding the whole dependency chain, replacement is built and then grafted onto the binaries that were initially referring to package. See Обновления безопасности, for more information on grafts.

For example, the command below grafts version 3.5.4 of GnuTLS onto Wget and all its dependencies, replacing references to the version of GnuTLS they currently refer to:

guix build --with-graft=gnutls=gnutls@3.5.4 wget

This has the advantage of being much faster than rebuilding everything. But there is a caveat: it works if and only if package and replacement are strictly compatible—for example, if they provide a library, the application binary interface (ABI) of those libraries must be compatible. If replacement is somehow incompatible with package, then the resulting package may be unusable. Use with care!

--with-debug-info=package

Build package in a way that preserves its debugging info and graft it onto packages that depend on it. This is useful if package does not already provide debugging info as a debug output (see Установка файлов отладки).

For example, suppose you’re experiencing a crash in Inkscape and would like to see what’s up in GLib, a library deep down in Inkscape’s dependency graph. GLib lacks a debug output, so debugging is tough. Fortunately, you rebuild GLib with debugging info and tack it on Inkscape:

guix install inkscape --with-debug-info=glib

Only GLib needs to be recompiled so this takes a reasonable amount of time. See Установка файлов отладки, for more info.

Примечание: Under the hood, this option works by passing the ‘#:strip-binaries? #f’ to the build system of the package of interest (see Системы сборки). Most build systems support that option but some do not. In that case, an error is raised.

Likewise, if a C/C++ package is built without -g (which is rarely the case), debugging info will remain unavailable even when #:strip-binaries? is false.

--with-c-toolchain=package=toolchain

This option changes the compilation of package and everything that depends on it so that they get built with toolchain instead of the default GNU tool chain for C/C++.

Рассмотрим пример:

guix build octave-cli \
  --with-c-toolchain=fftw=gcc-toolchain@10 \
  --with-c-toolchain=fftwf=gcc-toolchain@10

The command above builds a variant of the fftw and fftwf packages using version 10 of gcc-toolchain instead of the default tool chain, and then builds a variant of the GNU Octave command-line interface using them. GNU Octave itself is also built with gcc-toolchain@10.

This other example builds the Hardware Locality (hwloc) library and its dependents up to intel-mpi-benchmarks with the Clang C compiler:

guix build --with-c-toolchain=hwloc=clang-toolchain \
           intel-mpi-benchmarks

Примечание: There can be application binary interface (ABI) incompatibilities among tool chains. This is particularly true of the C++ standard library and run-time support libraries such as that of OpenMP. By rebuilding all dependents with the same tool chain, --with-c-toolchain minimizes the risks of incompatibility but cannot entirely eliminate them. Choose package wisely.

--with-git-url=package=url

Build package from the latest commit of the master branch of the Git repository at url. Git sub-modules of the repository are fetched, recursively.

For example, the following command builds the NumPy Python library against the latest commit of the master branch of Python itself:

guix build python-numpy \
  --with-git-url=python=https://github.com/python/cpython

This option can also be combined with --with-branch or --with-commit (see below).

Obviously, since it uses the latest commit of the given branch, the result of such a command varies over time. Nevertheless it is a convenient way to rebuild entire software stacks against the latest commit of one or more packages. This is particularly useful in the context of continuous integration (CI).

Checkouts are kept in a cache under ~/.cache/guix/checkouts to speed up consecutive accesses to the same repository. You may want to clean it up once in a while to save disk space.

--with-branch=package=branch

Build package from the latest commit of branch. If the source field of package is an origin with the git-fetch method (see Интерфейс origin) or a git-checkout object, the repository URL is taken from that source. Otherwise you have to use --with-git-url to specify the URL of the Git repository.

For instance, the following command builds guile-sqlite3 from the latest commit of its master branch, and then builds guix (which depends on it) and cuirass (which depends on guix) against this specific guile-sqlite3 build:

guix build --with-branch=guile-sqlite3=master cuirass
--with-commit=package=commit

This is similar to --with-branch, except that it builds from commit rather than the tip of a branch. commit must be a valid Git commit SHA1 identifier or a tag.

--with-patch=package=file

Add file to the list of patches applied to package, where package is a spec such as python@3.8 or glibc. file must contain a patch; it is applied with the flags specified in the origin of package (see Интерфейс origin), which by default includes -p1 (see patch Directories in Comparing and Merging Files).

As an example, the command below rebuilds Coreutils with the GNU C Library (glibc) patched with the given patch:

guix build coreutils --with-patch=glibc=./glibc-frob.patch

In this example, glibc itself as well as everything that leads to Coreutils in the dependency graph is rebuilt.

--with-latest=package

So you like living on the bleeding edge? This option is for you! It replaces occurrences of package in the dependency graph with its latest upstream version, as reported by guix refresh (see Запуск guix refresh).

It does so by determining the latest upstream release of package (if possible), downloading it, and authenticating it if it comes with an OpenPGP signature.

As an example, the command below builds Guix against the latest version of Guile-JSON:

guix build guix --with-latest=guile-json

There are limitations. First, in cases where the tool cannot or does not know how to authenticate source code, you are at risk of running malicious code; a warning is emitted in this case. Second, this option simply changes the source used in the existing package definitions, which is not always sufficient: there might be additional dependencies that need to be added, patches to apply, and more generally the quality assurance work that Guix developers normally do will be missing.

You’ve been warned! In all the other cases, it’s a snappy way to stay on top. We encourage you to submit patches updating the actual package definitions once you have successfully tested an upgrade (see Содействие).

--without-tests=package

Build package without running its tests. This can be useful in situations where you want to skip the lengthy test suite of a intermediate package, or if a package’s test suite fails in a non-deterministic fashion. It should be used with care because running the test suite is a good way to ensure a package is working as intended.

Turning off tests leads to a different store item. Consequently, when using this option, anything that depends on package must be rebuilt, as in this example:

guix install --without-tests=python python-notebook

The command above installs python-notebook on top of python built without running its test suite. To do so, it also rebuilds everything that depends on python, including python-notebook itself.

Internally, --without-tests relies on changing the #:tests? option of a package’s check phase (see Системы сборки). Note that some packages use a customized check phase that does not respect a #:tests? #f setting. Therefore, --without-tests has no effect on these packages.

Wondering how to achieve the same effect using Scheme code, for example in your manifest, or how to write your own package transformation? See Описание пакетов, for an overview of the programming interfaces available.


Next: , Previous: , Up: Запуск guix build   [Contents][Index]

9.1.3 Дополнительные параметры сборки

Параметры командной строки, представленные ниже, относятся к guix build.

--quiet
-q

Build quietly, without displaying the build log; this is equivalent to --verbosity=0. Upon completion, the build log is kept in /var (or similar) and can always be retrieved using the --log-file option.

--file=file
-f file

Build the package, derivation, or other file-like object that the code within file evaluates to (see file-like objects).

As an example, file might contain a package 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+))

The file may also contain a JSON representation of one or more package definitions. Running guix build -f on hello.json with the following contents would result in building the packages myhello and greeter:

[
  {
    "name": "myhello",
    "version": "2.10",
    "source": "mirror://gnu/hello/hello-2.10.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "tests?": false
    }
    "home-page": "https://www.gnu.org/software/hello/",
    "synopsis": "Hello, GNU world: An example GNU package",
    "description": "GNU Hello prints a greeting.",
    "license": "GPL-3.0+",
    "native-inputs": ["gettext"]
  },
  {
    "name": "greeter",
    "version": "1.0",
    "source": "https://example.com/greeter-1.0.tar.gz",
    "build-system": "gnu",
    "arguments": {
      "test-target": "foo",
      "parallel-build?": false,
    },
    "home-page": "https://example.com/",
    "synopsis": "Greeter using GNU Hello",
    "description": "This is a wrapper around GNU Hello.",
    "license": "GPL-3.0+",
    "inputs": ["myhello", "hello"]
  }
]
--manifest=manifest
-m manifest

Build all packages listed in the given manifest (see --manifest).

--expression=expr
-e expr

Build the package or derivation expr evaluates to.

For example, expr may be (@ (gnu packages guile) guile-1.8), which unambiguously designates this specific variant of version 1.8 of Guile.

Alternatively, expr may be a G-expression, in which case it is used as a build program passed to gexp->derivation (see G-Expressions).

Lastly, expr may refer to a zero-argument monadic procedure (see Устройство склада). The procedure must return a derivation as a monadic value, which is then passed through run-with-store.

--source
-S

Build the source derivations of the packages, rather than the packages themselves.

For instance, guix build -S gcc returns something like /gnu/store/…-gcc-4.7.2.tar.bz2, which is the GCC source tarball.

The returned source tarball is the result of applying any patches and code snippets specified in the package origin (see Описание пакетов).

As with other derivations, the result of building a source derivation can be verified using the --check option (see build-check). This is useful to validate that a (potentially already built or substituted, thus cached) package source matches against its declared hash.

Note that guix build -S compiles the sources only of the specified packages. They do not include the sources of statically linked dependencies and by themselves are insufficient for reproducing the packages.

--sources

Fetch and return the source of package-or-derivation and all their dependencies, recursively. This is a handy way to obtain a local copy of all the source code needed to build packages, allowing you to eventually build them even without network access. It is an extension of the --source option and can accept one of the following optional argument values:

package

This value causes the --sources option to behave in the same way as the --source option.

all

Build the source derivations of all packages, including any source that might be listed as inputs. This is the default value.

$ guix build --sources tzdata
The following derivations will be built:
   /gnu/store/…-tzdata2015b.tar.gz.drv
   /gnu/store/…-tzcode2015b.tar.gz.drv
transitive

Build the source derivations of all packages, as well of all transitive inputs to the packages. This can be used e.g. to prefetch package source for later offline building.

$ guix build --sources=transitive tzdata
The following derivations will be built:
   /gnu/store/…-tzcode2015b.tar.gz.drv
   /gnu/store/…-findutils-4.4.2.tar.xz.drv
   /gnu/store/…-grep-2.21.tar.xz.drv
   /gnu/store/…-coreutils-8.23.tar.xz.drv
   /gnu/store/…-make-4.1.tar.xz.drv
   /gnu/store/…-bash-4.3.tar.xz.drv
…
--system=system
-s system

Attempt to build for system—e.g., i686-linux—instead of the system type of the build host. The guix build command allows you to repeat this option several times, in which case it builds for all the specified systems; other commands ignore extraneous -s options.

Примечание: The --system flag is for native compilation and must not be confused with cross-compilation. See --target below for information on cross-compilation.

An example use of this is on Linux-based systems, which can emulate different personalities. For instance, passing --system=i686-linux on an x86_64-linux system or --system=armhf-linux on an aarch64-linux system allows you to build packages in a complete 32-bit environment.

Примечание: Building for an armhf-linux system is unconditionally enabled on aarch64-linux machines, although certain aarch64 chipsets do not allow for this functionality, notably the ThunderX.

Similarly, when transparent emulation with QEMU and binfmt_misc is enabled (see qemu-binfmt-service-type), you can build for any system for which a QEMU binfmt_misc handler is installed.

Builds for a system other than that of the machine you are using can also be offloaded to a remote machine of the right architecture. See Установка демона разгрузки, for more information on offloading.

--target=triplet

Cross-build for triplet, which must be a valid GNU triplet, such as "aarch64-linux-gnu" (see GNU configuration triplets in Autoconf).

--check

Rebuild package-or-derivation, which are already available in the store, and raise an error if the build results are not bit-for-bit identical.

This mechanism allows you to check whether previously installed substitutes are genuine (see Подстановки), or whether the build result of a package is deterministic. See Запуск guix challenge, for more background information and tools.

При использовании вместе с --keep-failed различные результаты сохраняются на складе под /gnu/store/…-check. Это делает возможным просмотр различий между двумя результатами.

--repair

Attempt to repair the specified store items, if they are corrupt, by re-downloading or rebuilding them.

This operation is not atomic and thus restricted to root.

--derivations
-d

Return the derivation paths, not the output paths, of the given packages.

--root=file
-r file

Make file a symlink to the result, and register it as a garbage collector root.

Consequently, the results of this guix build invocation are protected from garbage collection until file is removed. When that option is omitted, build results are eligible for garbage collection as soon as the build completes. See Вызов guix gc, for more on GC roots.

--log-file

Return the build log file names or URLs for the given package-or-derivation, or raise an error if build logs are missing.

This works regardless of how packages or derivations are specified. For instance, the following invocations are equivalent:

guix build --log-file $(guix build -d guile)
guix build --log-file $(guix build guile)
guix build --log-file guile
guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

If a log is unavailable locally, and unless --no-substitutes is passed, the command looks for a corresponding log on one of the substitute servers (as specified with --substitute-urls).

So for instance, imagine you want to see the build log of GDB on MIPS, but you are actually on an x86_64 machine:

$ guix build --log-file gdb -s aarch64-linux
https://ci.guix.gnu.org/log/…-gdb-7.10

You can freely access a huge library of build logs!


Previous: , Up: Запуск guix build   [Contents][Index]

9.1.4 Отладка ошибок сборки

When defining a new package (see Описание пакетов), you will probably find yourself spending some time debugging and tweaking the build until it succeeds. To do that, you need to operate the build commands yourself in an environment as close as possible to the one the build daemon uses.

To that end, the first thing to do is to use the --keep-failed or -K option of guix build, which will keep the failed build tree in /tmp or whatever directory you specified as TMPDIR (see --keep-failed).

From there on, you can cd to the failed build tree and source the environment-variables file, which contains all the environment variable definitions that were in place when the build failed. So let’s say you’re debugging a build failure in package foo; a typical session would look like this:

$ guix build foo -K
… build fails
$ cd /tmp/guix-build-foo.drv-0
$ source ./environment-variables
$ cd foo-1.2

Now, you can invoke commands as if you were the daemon (almost) and troubleshoot your build process.

Sometimes it happens that, for example, a package’s tests pass when you run them manually but they fail when the daemon runs them. This can happen because the daemon runs builds in containers where, unlike in our environment above, network access is missing, /bin/sh does not exist, etc. (see Установка окружения сборки).

In such cases, you may need to run inspect the build process from within a container similar to the one the build daemon creates:

$ guix build -K foo
…
$ cd /tmp/guix-build-foo.drv-0
$ guix environment --no-grafts -C foo --ad-hoc strace gdb
[env]# source ./environment-variables
[env]# cd foo-1.2

Here, guix environment -C creates a container and spawns a new shell in it (see Запуск guix environment). The --ad-hoc strace gdb part adds the strace and gdb commands to the container, which you may find handy while debugging. The --no-grafts option makes sure we get the exact same environment, with ungrafted packages (see Обновления безопасности, for more info on grafts).

To get closer to a container like that used by the build daemon, we can remove /bin/sh:

[env]# rm /bin/sh

(Don’t worry, this is harmless: this is all happening in the throw-away container created by guix environment.)

The strace command is probably not in the search path, but we can run:

[env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

In this way, not only you will have reproduced the environment variables the daemon uses, you will also be running the build process in a container similar to the one the daemon uses.


Next: , Previous: , Up: Утилиты   [Contents][Index]

9.2 Invoking guix edit

So many packages, so many source files! The guix edit command facilitates the life of users and packagers by pointing their editor at the source file containing the definition of the specified packages. For instance:

guix edit gcc@4.9 vim

launches the program specified in the VISUAL or in the EDITOR environment variable to view the recipe of GCC 4.9.3 and that of Vim.

If you are using a Guix Git checkout (see Сборка из Git), or have created your own packages on GUIX_PACKAGE_PATH (see Пакетные модули), you will be able to edit the package recipes. In other cases, you will be able to examine the read-only recipes for packages currently in the store.

Instead of GUIX_PACKAGE_PATH, the command-line option --load-path=directory (or in short -L directory) allows you to add directory to the front of the package module search path and so make your own packages visible.


Next: , Previous: , Up: Утилиты   [Contents][Index]

9.3 Invoking guix download

When writing a package definition, developers typically need to download a source tarball, compute its SHA256 hash, and write that hash in the package definition (see Описание пакетов). The guix download tool helps with this task: it downloads a file from the given URI, adds it to the store, and prints both its file name in the store and its SHA256 hash.

The fact that the downloaded file is added to the store saves bandwidth: when the developer eventually tries to build the newly defined package with guix build, the source tarball will not have to be downloaded again because it is already in the store. It is also a convenient way to temporarily stash files, which may be deleted eventually (see Вызов guix gc).

The guix download command supports the same URIs as used in package definitions. In particular, it supports mirror:// URIs. https URIs (HTTP over TLS) are supported provided the Guile bindings for GnuTLS are available in the user’s environment; when they are not available, an error is raised. See how to install the GnuTLS bindings for Guile in GnuTLS-Guile, for more information.

guix download verifies HTTPS server certificates by loading the certificates of X.509 authorities from the directory pointed to by the SSL_CERT_DIR environment variable (see Сертификаты X.509), unless --no-check-certificate is used.

The following options are available:

--hash=algorithm
-H algorithm

Compute a hash using the specified algorithm. See Запуск guix hash, for more information.

--format=fmt
-f fmt

Write the hash in the format specified by fmt. For more information on the valid values for fmt, see Запуск guix hash.

--no-check-certificate

Do not validate the X.509 certificates of HTTPS servers.

When using this option, you have absolutely no guarantee that you are communicating with the authentic server responsible for the given URL, which makes you vulnerable to “man-in-the-middle” attacks.

--output=file
-o file

Save the downloaded file to file instead of adding it to the store.


Next: , Previous: , Up: Утилиты   [Contents][Index]

9.4 Invoking guix hash

The guix hash command computes the hash of a file. It is primarily a convenience tool for anyone contributing to the distribution: it computes the cryptographic hash of a file, which can be used in the definition of a package (see Описание пакетов).

Основной синтаксис:

guix hash option file

When file is - (a hyphen), guix hash computes the hash of data read from standard input. guix hash has the following options:

--hash=algorithm
-H algorithm

Compute a hash using the specified algorithm, sha256 by default.

algorithm must the name of a cryptographic hash algorithm supported by Libgcrypt via Guile-Gcrypt—e.g., sha512 or sha3-256 (see Hash Functions in Guile-Gcrypt Reference Manual).

--format=fmt
-f fmt

Write the hash in the format specified by fmt.

Supported formats: base64, nix-base32, base32, base16 (hex and hexadecimal can be used as well).

If the --format option is not specified, guix hash will output the hash in nix-base32. This representation is used in the definitions of packages.

--recursive
-r

Compute the hash on file recursively.

In this case, the hash is computed on an archive containing file, including its children if it is a directory. Some of the metadata of file is part of the archive; for instance, when file is a regular file, the hash is different depending on whether file is executable or not. Metadata such as time stamps has no impact on the hash (see Вызов guix archive).

--exclude-vcs
-x

When combined with --recursive, exclude version control system directories (.bzr, .git, .hg, etc.).

As an example, here is how you would compute the hash of a Git checkout, which is useful when using the git-fetch method (see Интерфейс origin):

$ git clone http://example.org/foo.git
$ cd foo
$ guix hash -rx .

Next: , Previous: , Up: Утилиты   [Contents][Index]

9.5 Invoking guix import

The guix import command is useful for people who would like to add a package to the distribution with as little work as possible—a legitimate demand. The command knows of a few repositories from which it can “import” package metadata. The result is a package definition, or a template thereof, in the format we know (see Описание пакетов).

Основной синтаксис:

guix import importer options

importer specifies the source from which to import package metadata, and options specifies a package identifier and other options specific to importer.

Some of the importers rely on the ability to run the gpgv command. For these, GnuPG must be installed and in $PATH; run guix install gnupg if needed.

Currently, the available “importers” are:

gnu

Import metadata for the given GNU package. This provides a template for the latest version of that GNU package, including the hash of its source tarball, and its canonical synopsis and description.

Additional information such as the package dependencies and its license needs to be figured out manually.

For example, the following command returns a package definition for GNU Hello:

guix import gnu hello

Specific command-line options are:

--key-download=policy

As for guix refresh, specify the policy to handle missing OpenPGP keys when verifying the package signature. See --key-download.

pypi

Import metadata from the Python Package Index. Information is taken from the JSON-formatted description available at pypi.python.org and usually includes all the relevant information, including package dependencies. For maximum efficiency, it is recommended to install the unzip utility, so that the importer can unzip Python wheels and gather data from them.

The command below imports metadata for the itsdangerous Python package:

guix import pypi itsdangerous
--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

gem

Import metadata from RubyGems. Information is taken from the JSON-formatted description available at rubygems.org and includes most relevant information, including runtime dependencies. There are some caveats, however. The metadata doesn’t distinguish between synopses and descriptions, so the same string is used for both fields. Additionally, the details of non-Ruby dependencies required to build native extensions is unavailable and left as an exercise to the packager.

The command below imports metadata for the rails Ruby package:

guix import gem rails
--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

cpan

Import metadata from MetaCPAN. Information is taken from the JSON-formatted metadata provided through MetaCPAN’s API and includes most relevant information, such as module dependencies. License information should be checked closely. If Perl is available in the store, then the corelist utility will be used to filter core modules out of the list of dependencies.

The command command below imports metadata for the Acme::Boolean Perl module:

guix import cpan Acme::Boolean
cran

Import metadata from CRAN, the central repository for the GNU R statistical and graphical environment.

Information is extracted from the DESCRIPTION file of the package.

The command command below imports metadata for the Cairo R package:

guix import cran Cairo

When --recursive is added, the importer will traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

When --style=specification is added, the importer will generate package definitions whose inputs are package specifications instead of references to package variables. This is useful when generated package definitions are to be appended to existing user modules, as the list of used package modules need not be changed. The default is --style=variable.

When --archive=bioconductor is added, metadata is imported from Bioconductor, a repository of R packages for the analysis and comprehension of high-throughput genomic data in bioinformatics.

Information is extracted from the DESCRIPTION file contained in the package archive.

The command below imports metadata for the GenomicRanges R package:

guix import cran --archive=bioconductor GenomicRanges

Finally, you can also import R packages that have not yet been published on CRAN or Bioconductor as long as they are in a git repository. Use --archive=git followed by the URL of the git repository:

guix import cran --archive=git https://github.com/immunogenomics/harmony
texlive

Import metadata from CTAN, the comprehensive TeX archive network for TeX packages that are part of the TeX Live distribution.

Information about the package is obtained through the XML API provided by CTAN, while the source code is downloaded from the SVN repository of the Tex Live project. This is done because the CTAN does not keep versioned archives.

The command command below imports metadata for the fontspec TeX package:

guix import texlive fontspec

When --archive=directory is added, the source code is downloaded not from the latex sub-directory of the texmf-dist/source tree in the TeX Live SVN repository, but from the specified sibling directory under the same root.

The command below imports metadata for the ifxetex package from CTAN while fetching the sources from the directory texmf/source/generic:

guix import texlive --archive=generic ifxetex
json

Import package metadata from a local JSON file. Consider the following example package definition in JSON format:

{
  "name": "hello",
  "version": "2.10",
  "source": "mirror://gnu/hello/hello-2.10.tar.gz",
  "build-system": "gnu",
  "home-page": "https://www.gnu.org/software/hello/",
  "synopsis": "Hello, GNU world: An example GNU package",
  "description": "GNU Hello prints a greeting.",
  "license": "GPL-3.0+",
  "native-inputs": ["gettext"]
}

The field names are the same as for the <package> record (See Описание пакетов). References to other packages are provided as JSON lists of quoted package specification strings such as guile or guile@2.0.

The importer also supports a more explicit source definition using the common fields for <origin> records:

{
  …
  "source": {
    "method": "url-fetch",
    "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
    "sha256": {
      "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
    }
  }
  …
}

The command below reads metadata from the JSON file hello.json and outputs a package expression:

guix import json hello.json
hackage

Import metadata from the Haskell community’s central package archive Hackage. Information is taken from Cabal files and includes all the relevant information, including package dependencies.

Specific command-line options are:

--stdin
-s

Read a Cabal file from standard input.

--no-test-dependencies
-t

Do not include dependencies required only by the test suites.

--cabal-environment=alist
-e alist

alist is a Scheme alist defining the environment in which the Cabal conditionals are evaluated. The accepted keys are: os, arch, impl and a string representing the name of a flag. The value associated with a flag has to be either the symbol true or false. The value associated with other keys has to conform to the Cabal file format definition. The default value associated with the keys os, arch and impl is ‘linux’, ‘x86_64’ and ‘ghc’, respectively.

--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

The command below imports metadata for the latest version of the HTTP Haskell package without including test dependencies and specifying the value of the flag ‘network-uri’ as false:

guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

A specific package version may optionally be specified by following the package name by an at-sign and a version number as in the following example:

guix import hackage mtl@2.1.3.1
stackage

The stackage importer is a wrapper around the hackage one. It takes a package name, looks up the package version included in a long-term support (LTS) Stackage release and uses the hackage importer to retrieve its metadata. Note that it is up to you to select an LTS release compatible with the GHC compiler used by Guix.

Specific command-line options are:

--no-test-dependencies
-t

Do not include dependencies required only by the test suites.

--lts-version=version
-l version

version is the desired LTS release version. If omitted the latest release is used.

--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

The command below imports metadata for the HTTP Haskell package included in the LTS Stackage release version 7.18:

guix import stackage --lts-version=7.18 HTTP
elpa

Import metadata from an Emacs Lisp Package Archive (ELPA) package repository (see Packages in The GNU Emacs Manual).

Specific command-line options are:

--archive=repo
-a repo

repo identifies the archive repository from which to retrieve the information. Currently the supported repositories and their identifiers are:

  • - GNU, selected by the gnu identifier. This is the default.

    Packages from elpa.gnu.org are signed with one of the keys contained in the GnuPG keyring at share/emacs/25.1/etc/package-keyring.gpg (or similar) in the emacs package (see ELPA package signatures in The GNU Emacs Manual).

  • - MELPA-Stable, selected by the melpa-stable identifier.
  • - MELPA, selected by the melpa identifier.
--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

crate

Import metadata from the crates.io Rust package repository crates.io, as in this example:

guix import crate blake2-rfc

The crate importer also allows you to specify a version string:

guix import crate constant-time-eq@0.1.0

Дополительные опции включаю:

--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

opam

Import metadata from the OPAM package repository used by the OCaml community.

Дополительные опции включаю:

--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

--repo

Select the given repository (a repository name). Possible values include:

  • opam, the default opam repository,
  • coq or coq-released, the stable repository for coq packages,
  • coq-core-dev, the repository that contains development versions of coq,
  • coq-extra-dev, the repository that contains development versions пакетов coq.
go

Import metadata for a Go module using proxy.golang.org.

guix import go gopkg.in/yaml.v2

It is possible to use a package specification with a @VERSION suffix to import a specific version.

Дополительные опции включаю:

--recursive
-r

Traverse the dependency graph of the given upstream package recursively and generate package expressions for all those packages that are not yet in Guix.

--pin-versions

When using this option, the importer preserves the exact versions of the Go modules dependencies instead of using their latest available versions. This can be useful when attempting to import packages that recursively depend on former versions of themselves to build. When using this mode, the symbol of the package is made by appending the version to its name, so that multiple versions of the same package can coexist.

The structure of the guix import code is modular. It would be useful to have more importers for other package formats, and your help is welcome here (see Содействие).


Next: , Previous: , Up: Утилиты   [Contents][Index]

9.6 Invoking guix refresh

The primary audience of the guix refresh command is packagers. As a user, you may be interested in the --with-latest option, which can bring you package update superpowers built upon guix refresh (see --with-latest). By default, guix refresh reports any packages provided by the distribution that are outdated compared to the latest upstream version, like this:

$ guix refresh
gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

Alternatively, one can specify packages to consider, in which case a warning is emitted for packages that lack an updater:

$ guix refresh coreutils guile guile-ssh
gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

guix refresh browses the upstream repository of each package and determines the highest version number of the releases therein. The command knows how to update specific types of packages: GNU packages, ELPA packages, etc.—see the documentation for --type below. There are many packages, though, for which it lacks a method to determine whether a new upstream release is available. However, the mechanism is extensible, so feel free to get in touch with us to add a new method!

--recursive

Consider the packages specified, and all the packages upon which they depend.

$ guix refresh --recursive coreutils
gnu/packages/acl.scm:40:13: acl would be upgraded from 2.2.53 to 2.3.1
gnu/packages/m4.scm:30:12: 1.4.18 is already the latest version of m4
gnu/packages/xml.scm:68:2: warning: no updater for expat
gnu/packages/multiprecision.scm:40:12: 6.1.2 is already the latest version of gmp
…

Sometimes the upstream name differs from the package name used in Guix, and guix refresh needs a little help. Most updaters honor the upstream-name property in package definitions, which can be used to that effect:

(define-public network-manager
  (package
    (name "network-manager")
    ;; …
    (properties '((upstream-name . "NetworkManager")))))

When passed --update, it modifies distribution source files to update the version numbers and source tarball hashes of those package recipes (see Описание пакетов). This is achieved by downloading each package’s latest source tarball and its associated OpenPGP signature, authenticating the downloaded tarball against its signature using gpgv, and finally computing its hash—note that GnuPG must be installed and in $PATH; run guix install gnupg if needed.

When the public key used to sign the tarball is missing from the user’s keyring, an attempt is made to automatically retrieve it from a public key server; when this is successful, the key is added to the user’s keyring; otherwise, guix refresh reports an error.

Поддерживаются следующие варианты:

--expression=expr
-e expr

Процедура, при выполнении которой возвращается пакет.

This is useful to precisely refer to a package, as in this example:

guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

This command lists the dependents of the “final” libc (essentially all the packages).

--update
-u

Update distribution source files (package recipes) in place. This is usually run from a checkout of the Guix source tree (see Запуск Guix перед его установкой):

$ ./pre-inst-env guix refresh -s non-core -u

See Описание пакетов, for more information on package definitions.

--select=[subset]
-s subset

Select all the packages in subset, one of core or non-core.

The core subset refers to all the packages at the core of the distribution—i.e., packages that are used to build “everything else”. This includes GCC, libc, Binutils, Bash, etc. Usually, changing one of these packages in the distribution entails a rebuild of all the others. Thus, such updates are an inconvenience to users in terms of build time or bandwidth used to achieve the upgrade.

The non-core subset refers to the remaining packages. It is typically useful in cases where an update of the core packages would be inconvenient.

--manifest=file
-m file

Select all the packages from the manifest in file. This is useful to check if any packages of the user manifest can be updated.

--type=updater
-t updater

Select only packages handled by updater (may be a comma-separated list of updaters). Currently, updater may be one of:

gnu

средство обновления пакетов GNU;

savannah

the updater for packages hosted at Savannah;

sourceforge

the updater for packages hosted at SourceForge;

gnome

средство обновления пакетов GNOME;

kde

средство обновления пакетов KDE;

xorg

средство обновления пакетов X.org;

kernel.org

средство обновления пакетов, размещенных на kernel.org;

elpa

the updater for ELPA packages;

cran

the updater for CRAN packages;

bioconductor

the updater for Bioconductor R packages;

cpan

the updater for CPAN packages;

pypi

the updater for PyPI packages.

gem

the updater for RubyGems packages.

github

средство обновления пакетов GitHub.

hackage

the updater for Hackage packages.

stackage

the updater for Stackage packages.

crate

the updater for Crates packages.

launchpad

the updater for Launchpad packages.

generic-html

a generic updater that crawls the HTML page where the source tarball of the package is hosted, when applicable.

For instance, the following command only checks for updates of Emacs packages hosted at elpa.gnu.org and for updates of CRAN packages:

$ guix refresh --type=elpa,cran
gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
--list-updaters
-L

List available updaters and exit (see --type above).

For each updater, display the fraction of packages it covers; at the end, display the fraction of packages covered by all these updaters.

In addition, guix refresh can be passed one or more package names, as in this example:

$ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8

The command above specifically updates the emacs and idutils packages. The --select option would have no effect in this case. You might also want to update definitions that correspond to the packages installed in your profile:

$ ./pre-inst-env guix refresh -u \
       $(guix package --list-installed | cut -f1)

When considering whether to upgrade a package, it is sometimes convenient to know which packages would be affected by the upgrade and should be checked for compatibility. For this the following option may be used when passing guix refresh one or more package names:

--list-dependent
-l

List top-level dependent packages that would need to be rebuilt as a result of upgrading one or more packages.

See the reverse-package type of guix graph, for information on how to visualize the list of dependents of a package.

Be aware that the --list-dependent option only approximates the rebuilds that would be required as a result of an upgrade. More rebuilds might be required under some circumstances.

$ guix refresh --list-dependent flex
Building the following 120 packages would ensure 213 dependent packages are rebuilt:
hop@2.4.0 geiser@0.4 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 …

The command above lists a set of packages that could be built to check for compatibility with an upgraded flex package.

--list-transitive

List all the packages which one or more packages depend upon.

$ guix refresh --list-transitive flex
flex@2.6.4 depends on the following 25 packages: perl@5.28.0 help2man@1.47.6
bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 …

The command above lists a set of packages which, when changed, would cause flex to be rebuilt.

The following options can be used to customize GnuPG operation:

--gpg=command

Use command as the GnuPG 2.x command. command is searched for in $PATH.

--keyring=file

Use file as the keyring for upstream keys. file must be in the keybox format. Keybox files usually have a name ending in .kbx and the GNU Privacy Guard (GPG) can manipulate these files (see kbxutil in Using the GNU Privacy Guard, for information on a tool to manipulate keybox files).

When this option is omitted, guix refresh uses ~/.config/guix/upstream/trustedkeys.kbx as the keyring for upstream signing keys. OpenPGP signatures are checked against keys from this keyring; missing keys are downloaded to this keyring as well (see --key-download below).

You can export keys from your default GPG keyring into a keybox file using commands like this one:

gpg --export rms@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx

Likewise, you can fetch keys to a specific keybox file like this:

gpg --no-default-keyring --keyring mykeyring.kbx \
  --recv-keys 27D586A4F8900854329FF09F1260E46482E63562

See --keyring in Using the GNU Privacy Guard, for more information on GPG’s --keyring option.

--key-download=policy

Handle missing OpenPGP keys according to policy, which may be one of:

всегда

Always download missing OpenPGP keys from the key server, and add them to the user’s GnuPG keyring.

никогда

Never try to download missing OpenPGP keys. Instead just bail out.

interactive

When a package signed with an unknown OpenPGP key is encountered, ask the user whether to download it or not. This is the default behavior.

--key-server=host

Use host as the OpenPGP key server when importing a public key.

--load-path=directory

Add directory to the front of the package module search path (see Пакетные модули).

Это позволяет пользователям определять свои собственные пакеты и делать их видимыми для инструментов командной строки.

The github updater uses the GitHub API to query for new releases. When used repeatedly e.g. when refreshing all packages, GitHub will eventually refuse to answer any further API requests. By default 60 API requests per hour are allowed, and a full refresh on all GitHub packages in Guix requires more than this. Authentication with GitHub through the use of an API token alleviates these limits. To use an API token, set the environment variable GUIX_GITHUB_TOKEN to a token procured from https://github.com/settings/tokens or otherwise.


Next: , Previous: , Up: Утилиты   [Contents][Index]

9.7 Вызов guix lint

The guix lint command is meant to help package developers avoid common errors and use a consistent style. It runs a number of checks on a given set of packages in order to find common mistakes in their definitions. Available checkers include (see --list-checkers for a complete list):

synopsis
description

Validate certain typographical and stylistic rules about package descriptions and synopses.

inputs-should-be-native

Identify inputs that should most likely be native inputs.

источник
home-page
mirror-url
github-url
source-file-name

Probe home-page and source URLs and report those that are invalid. Suggest a mirror:// URL when applicable. If the source URL redirects to a GitHub URL, recommend usage of the GitHub URL. Check that the source file name is meaningful, e.g. is not jus