This is guix.ru.info, produced by makeinfo version 6.8 from
guix.ru.texi.

Copyright © 2012–2025 Ludovic Courtès
Copyright © 2013, 2014, 2016, 2024 Andreas Enge
Copyright © 2013 Nikita Karetnikov
Copyright © 2014, 2015, 2016 Alex Kost
Copyright © 2015, 2016 Mathieu Lirzin
Copyright © 2014 Pierre-Antoine Rault
Copyright © 2015 Taylan Ulrich Bayırlı/Kammer
Copyright © 2015, 2016, 2017, 2019, 2020, 2021, 2023, 2025 Leo Famulari
Copyright © 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023 Ricardo
Wurmus
Copyright © 2016 Ben Woodcroft
Copyright © 2016, 2017, 2018, 2021 Chris Marusich
Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2025 Efraim
Flashner
Copyright © 2016 John Darrington
Copyright © 2016, 2017 Nikita Gillmann
Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025
Janneke Nieuwenhuizen
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Julien Lepiller
Copyright © 2016 Alex ter Weele
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Christopher Baines
Copyright © 2017, 2018, 2019 Clément Lassieur
Copyright © 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe
Copyright © 2017 Federico Beffa
Copyright © 2017, 2018, 2024, 2025 Carlo Zancanaro
Copyright © 2017 Thomas Danckaert
Copyright © 2017 humanitiesNerd
Copyright © 2017, 2021 Christine Lemmer-Webber
Copyright © 2017, 2018, 2019, 2020, 2021, 2022 Marius Bakke
Copyright © 2017, 2019, 2020, 2022 Hartmut Goebel
Copyright © 2017, 2019–2025 Maxim Cournoyer
Copyright © 2017–2022 Tobias Geerinckx-Rice
Copyright © 2017 George Clemmer
Copyright © 2017 Andy Wingo
Copyright © 2017, 2018, 2019, 2020, 2023, 2024, 2025 Arun Isaac
Copyright © 2017 nee
Copyright © 2018 Rutger Helling
Copyright © 2018, 2021, 2023, 2025 Oleg Pykhalov
Copyright © 2018 Mike Gerwitz
Copyright © 2018 Pierre-Antoine Rouby
Copyright © 2018, 2019 Gábor Boskovits
Copyright © 2018, 2019, 2020, 2022, 2023, 2024 Florian Pelz
Copyright © 2018 Laura Lazzati
Copyright © 2018 Alex Vong
Copyright © 2019 Josh Holland
Copyright © 2019, 2020 Diego Nicola Barbato
Copyright © 2019 Ivan Petkov
Copyright © 2019 Jakob L. Kreuze
Copyright © 2019 Kyle Andrews
Copyright © 2019 Alex Griffin
Copyright © 2019, 2020, 2021, 2022 Guillaume Le Vaillant
Copyright © 2020 Liliana Marie Prikler
Copyright © 2019, 2020, 2021, 2022, 2023 Simon Tournier
Copyright © 2020 Wiktor Żelazny
Copyright © 2020 Damien Cassou
Copyright © 2020 Jakub Kądziołka
Copyright © 2020 Jack Hill
Copyright © 2020 Naga Malleswari
Copyright © 2020, 2021 Brice Waegeneire
Copyright © 2020 R Veera Kumar
Copyright © 2020, 2021, 2022 Pierre Langlois
Copyright © 2020 pinoaffe
Copyright © 2020, 2023 André Batista
Copyright © 2020, 2021 Alexandru-Sergiu Marton
Copyright © 2020 raingloom
Copyright © 2020 Daniel Brooks
Copyright © 2020 John Soo
Copyright © 2020 Jonathan Brielmaier
Copyright © 2020 Edgar Vincent
Copyright © 2021, 2022 Maxime Devos
Copyright © 2021 B. Wilson
Copyright © 2021 Xinglu Chen
Copyright © 2021 Raghav Gururajan
Copyright © 2021 Domagoj Stolfa
Copyright © 2021 Hui Lu
Copyright © 2021 pukkamustard
Copyright © 2021 Alice Brenon
Copyright © 2021-2023 Josselin Poiret
Copyright © 2021, 2023 muradm
Copyright © 2021, 2022 Andrew Tropin
Copyright © 2021 Sarah Morgensen
Copyright © 2022 Remco van ’t Veer
Copyright © 2022 Aleksandr Vityazev
Copyright © 2022 Philip M^{c}Grath
Copyright © 2022 Karl Hallsby
Copyright © 2022 Justin Veilleux
Copyright © 2022 Reily Siegel
Copyright © 2022 Simon Streit
Copyright © 2022 (
Copyright © 2022 John Kehayias
Copyright © 2022⁠–⁠2023 Bruno Victal
Copyright © 2022 Ivan Vilata-i-Balaguer
Copyright © 2023-2025 Giacomo Leidi
Copyright © 2022 Antero Mejr
Copyright © 2023 Karl Hallsby
Copyright © 2023 Nathaniel Nicandro
Copyright © 2023 Tanguy Le Carrour
Copyright © 2023-2024 Zheng Junjie
Copyright © 2023 Brian Cully
Copyright © 2023 Felix Lechner
Copyright © 2023 Foundation Devices, Inc.
Copyright © 2023 Thomas Ieong
Copyright © 2023 Saku Laesvuori
Copyright © 2023 Graham James Addis
Copyright © 2023-2025 Tomas Volf
Copyright © 2024, 2025 Herman Rimm
Copyright © 2024 Matthew Trzcinski
Copyright © 2024 Richard Sent
Copyright © 2024 Dariqq
Copyright © 2024 Denis ’GNUtoo’ Carikli
Copyright © 2024 Fabio Natali
Copyright © 2024 Arnaud Daby-Seesaram
Copyright © 2024-2025 Nigko Yerden
Copyright © 2024 Troy Figiel
Copyright © 2024 Sharlatan Hellseher
Copyright © 2024 45mg
Copyright © 2024 Greg Hogan
Copyright © 2025 Sören Tempel
Copyright © 2025 Rostislav Svoboda
Copyright © 2025 Zacchaeus
Copyright © 2025 Sergio Pastor Pérez
Copyright © 2024 Evgeny Pisemsky
Copyright © 2025 jgart
Copyright © 2025 Artur Wroblewski
Copyright © 2025 Edouard Klein
Copyright © 2025 Rodion Goritskov
Copyright © 2025 dan
Copyright © 2025 Noé Lopez

   Разрешено копирование, распространение и/или модификация этого
документа на условиях лицензии свободной документации GNU (GNU FDL)
версии 1.3 или любой более поздней версии, опубликованной Фондом
свободного программного обеспечения (FSF), исключая неизменяемые секции,
исключая тексты, размещенные на переплёте и задней стороне обложки.
Копия лицензии включена в документ в разделе под названием "GNU Free
Documentation Licens".
INFO-DIR-SECTION Администрирование системы
START-INFO-DIR-ENTRY
* Guix.ru: (guix.ru).        Управление установленным ПО и настройка
                               системы.
* guix package: (guix.ru)Запуск guix package.  Установка, удаление и
                                                 обновление пакетов.
* guix gc: (guix.ru)Запуск guix gc.  Освобождение неиспользуемого места на
                                       диске.
* guix pull: (guix.ru)Запуск guix pull.  Обновление списка доступных
                                           пакетов.
* guix system: (guix.ru)Запуск guix system.  Управление конфигурацией ОС.
* guix deploy: (guix.ru)Запуск guix deploy.  Управление конфигурациями ОС на
                                               удалённых машинах.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Разработка программного обеспечения
START-INFO-DIR-ENTRY
* guix shell: (guix.ru)Запуск guix shell.  Creating software environments.
* guix environment: (guix.ru)Запуск guix environment.  Сборка среды
                                                         разработки с помощью
                                                         Guix.
* guix build: (guix.ru)Запуск guix build.  Сборка пакетов.
* guix pack: (guix.ru)Запуск guix pack.  Создание бинарных пакетов.
END-INFO-DIR-ENTRY


File: guix.ru.info,  Node: Каналы,  Next: Разработка,  Prev: Управление пакетами,  Up: Top

6 Каналы
********

Guix and its package collection are updated by running ‘guix pull’.  By
default ‘guix pull’ downloads and deploys Guix itself from the official
GNU Guix repository.  This can be customized by providing a file
specifying the set of “channels” to pull from (*note Запуск guix
pull::).  A channel specifies the 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.

* Menu:

* Указание дополнительных каналов::  Расширение коллекции пакетов.
* Использование отдельного канала Guix::  Использование кастомизированного
                                            Guix.
* Копирование Guix::         Запуск _exact same_ Guix.
* Customizing the System-Wide Guix::  Default channels on Guix System.
* Аутентификация канала::    Как Guix проверяет то, что получает.
* Каналы с заменителями::    Использование каналов с доступными
                               заменителями.
* Создание канала::          Как написать собственный канал.
* Пакетные модули в поддиректории::  Задание расположения пакетных модулей
                                       канала.
* Объявление зависимостей канала::  Как зависеть от других каналов.
* Указание авторизаций канала::  Авторизация авторов канала.
* Основной URL::             Отличие зеркала от оригинала.
* Написание новостей канала::  Передача информации пользователям канала.


File: guix.ru.info,  Node: Указание дополнительных каналов,  Next: Использование отдельного канала Guix,  Up: Каналы

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

Чтобы использовать канал, напишите ‘~/.config/guix/channels.scm’, чтобы
обозначить ‘guix pull’ скачивать оттуда _в дополнение_ к каналу(-ам)
Guix по умолчанию:

     ;; Add my personal packages to those Guix provides.
     (cons (channel
             (name 'my-personal-packages)
             (url "https://example.org/personal-packages.git"))
           %default-channels)

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

     $ guix describe
     Generation 19	Aug 27 2018 16:20:48
       guix d894ab8
         repository URL: https://git.guix.gnu.org/guix.git
         branch: master
         commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
       variant-packages dd3df5e
         repository URL: https://example.org/variant-packages.git
         branch: master
         commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb

The output of ‘guix describe’ above shows that we’re now running
Generation 19 and that it includes both Guix and packages from the
‘variant-packages’ channel (*note Вызов guix describe::).


File: guix.ru.info,  Node: Использование отдельного канала Guix,  Next: Копирование Guix,  Prev: Указание дополнительных каналов,  Up: Каналы

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

Канал, названный ‘guix’, обозначает, откуда должен скачиваться сам Guix
(его инструменты командной строки и коллекция пакетов).  Например,
предположим вы хотите обновиться из вашей собственной копии репозитория
Guix на ‘example.org’, а именно из ветки ‘super-hacks’, тогда можно
написать в ‘~/.config/guix/channels.scm’ следующую спецификацию:

     ;; Tell 'guix pull' to use my own repo.
     (list (channel
             (name 'guix)
             (url "https://example.org/my-guix.git")
             (branch "super-hacks")))

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

   Note that you can specify a local directory on the ‘url’ field above
if the channel that you intend to use resides on a local file system.
However, in this case ‘guix’ checks said directory for ownership before
any further processing.  This means that if the user is not the
directory owner, but wants to use it as their default, they will then
need to set it as a safe directory in their global git configuration
file.  Otherwise, ‘guix’ will refuse to even read it.  Supposing your
system-wide local directory is at ‘/src/guix.git’, you would then create
a git configuration file at ‘~/.gitconfig’ with the following contents:

     [safe]
             directory = /src/guix.git

This also applies to the root user unless when called with ‘sudo’ by the
directory owner.


File: guix.ru.info,  Node: Копирование Guix,  Next: Customizing the System-Wide Guix,  Prev: Использование отдельного канала Guix,  Up: Каналы

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

The ‘guix describe’ command shows precisely which commits were used to
build the instance of Guix we’re using (*note Вызов guix describe::).
We can replicate this instance on another machine or at a different
point in time by providing a channel specification “pinned” to these
commits that looks like this:

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

   To obtain this pinned channel specification, the easiest way is to
run ‘guix describe’ and to save its output in the ‘channels’ format in a
file, like so:

     guix describe -f channels > channels.scm

   Полученный файл ‘channels.scm’ можно передать в команды ‘guix pull’
(*note Запуск guix pull::) или ‘guix time-machine’ (*note Вызов guix
time-machine::) с опцией ‘-C’ , как в этом примере:

     guix time-machine -C channels.scm -- shell python -- python3

   Given the ‘channels.scm’ file, the command above will always fetch
the _exact same Guix instance_, then use that instance to run the exact
same Python (*note Запуск guix shell::).  On any machine, at any time,
it ends up running the exact same binaries, bit for bit.

   Pinned channels address a problem similar to “lock files” as
implemented by some deployment tools—they let you pin and reproduce a
set of packages.  In the case of Guix though, you are effectively
pinning the entire package set as defined at the given channel commits;
in fact, you are pinning all of Guix, including its core modules and
command-line tools.  You’re also getting strong guarantees that you are,
indeed, obtaining the exact same software.

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


File: guix.ru.info,  Node: Customizing the System-Wide Guix,  Next: Аутентификация канала,  Prev: Копирование Guix,  Up: Каналы

6.4 Customizing the System-Wide Guix
====================================

If you’re running Guix System or building system images with it, maybe
you will want to customize the system-wide ‘guix’ it
provides—specifically, ‘/run/current-system/profile/bin/guix’.  For
example, you might want to provide additional channels or to pin its
revision.

   This can be done using the ‘guix-for-channels’ procedure, which
returns a package for the given channels, and using it as part of your
operating system configuration, as in this example:

     (use-modules (gnu packages package-management)
                  (guix channels))

     (define my-channels
       ;; Channels that should be available to
       ;; /run/current-system/profile/bin/guix.
       (append
        (list (channel
               (name 'guix-science)
               (url "https://codeberg.org/guix-science/guix-science")
               (branch "master")))
        %default-channels))

     (operating-system
       ;; ...
       (services
         ;; Change the package used by 'guix-service-type'.
         (modify-services %base-services
           (guix-service-type
            config => (guix-configuration
                       (inherit config)
                       (channels my-channels)
                       (guix (guix-for-channels my-channels)))))))

   The resulting operating system will have both the ‘guix’ and the
‘guix-science’ channels visible by default.  The ‘channels’ field of
‘guix-configuration’ above further ensures that
‘/etc/guix/channels.scm’, which is used by ‘guix pull’, specifies the
same set of channels (*note ‘channels’ field of ‘guix-configuration’:
guix-configuration-channels.).

   The ‘(gnu packages package-management)’ module exports the
‘guix-for-channels’ procedure, described below.

 -- Procedure: guix-for-channels CHANNELS
     Return a package corresponding to CHANNELS.

     The result is a “regular” package, which can be used in
     ‘guix-configuration’ as shown above or in any other place that
     expects a package.


File: guix.ru.info,  Node: Аутентификация канала,  Next: Каналы с заменителями,  Prev: Customizing the System-Wide Guix,  Up: Каналы

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

‘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 канала из
надежного источника, так как это основа вашего доверия.

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


File: guix.ru.info,  Node: Каналы с заменителями,  Next: Создание канала,  Prev: Аутентификация канала,  Up: Каналы

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

При запуске ‘guix pull’ Guix сначала скомпилирует определения каждого
доступного пакета.  Это тяжелая операция, для которой могут быть
доступны заменители (*note Подстановки::).  Следующий фрагмент в
‘channels.scm’ гарантирует, что ‘guix pull’ использует последний коммит
с доступными заменами для определений пакетов: это делается путем
запроса к серверу непрерывной интеграции по адресу
<https://ci.guix.gnu.org>.

     (use-package-modules guile emacs)

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

   Учтите, что это не означает, что все пакеты, которые вы установите
после запуска ‘guix pull’, будут иметь доступные заменители.  Это только
гарантирует, что ‘guix pull’ не будет пытаться скомпилировать
определения пакетов.  Это особенно полезно при использовании машин с
ограниченными ресурсами.


File: guix.ru.info,  Node: Создание канала,  Next: Пакетные модули в поддиректории,  Prev: Каналы с заменителями,  Up: Каналы

6.7 Создание канала
===================

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.  By creating a “channel”, you can
use and publish such a package collection.  This involves the following
steps:

  1. A channel lives in a Git repository so the first step, when
     creating a channel, is to create its repository:

          mkdir my-channel
          cd my-channel
          git init

  2. The next step is to create files containing package modules (*note
     Пакетные модули::), each of which will contain one or more package
     definitions (*note Описание пакетов::).  A channel can provide
     things other than packages, such as build systems or services;
     we’re using packages as it’s the most common use case.

     For example, Alice might want to provide a module called ‘(alice
     packages greetings)’ that will provide her favorite “hello world”
     implementations.  To do that Alice will create a directory
     corresponding to that module name.

          mkdir -p alice/packages
          $EDITOR alice/packages/greetings.scm
          git add alice/packages/greetings.scm

     You can name your package modules however you like; the main
     constraint to keep in mind is to avoid name clashes with other
     package collections, which is why our hypothetical Alice wisely
     chose the ‘(alice packages ...)’ name space.

     Note that you can also place modules in a sub-directory of the
     repository; *note Пакетные модули в поддиректории::, for more info
     on that.

  3. With this first module in place, the next step is to test the
     packages it provides.  This can be done with ‘guix build’, which
     needs to be told to look for modules in the Git checkout.  For
     example, assuming ‘(alice packages greetings)’ provides a package
     called ‘hi-from-alice’, Alice will run this command from the Git
     checkout:

          guix build -L. hi-from-alice

     ...  where ‘-L.’ adds the current directory to Guile’s load path
     (*note (guile)Load Paths::).

  4. It might take Alice a few iterations to obtain satisfying package
     definitions.  Eventually Alice will commit this file:

          git commit

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

  5. To use Alice’s channel, anyone can now add it to their channel file
     (*note Указание дополнительных каналов::) and run ‘guix pull’
     (*note Запуск guix pull::):

          $EDITOR ~/.config/guix/channels.scm
          guix pull

     Guix will now behave as if the root directory of that channel’s Git
     repository had been permanently added to the Guile load path.  In
     this example, ‘(alice packages greetings)’ will automatically be
     found by the ‘guix’ command.

   Voilà!

     Предупреждение: Before you publish your channel, we would like to
     share a few words of caution:

        • Перед публикацией канала, пожалуйста, рассмотрите возможность
          поделиться вашими определениями пакетов со сборником Guix
          (*note Содействие::).  Guix, как проект, открыт свободному
          программному обеспечению любого назначения, и пакеты в
          сборнике Guix готовы и доступны для использования всеми
          пользователями Guix и прошли проверку качества.

        • Package modules and package definitions are Scheme code that
          uses various programming interfaces (APIs).  Those may
          occasionally change, in accordance with our deprecation policy
          (*note Deprecation Policy::), and it is your responsibility as
          a channel author to adjust your code accordingly.

        • Вывод: если вы используете внешний канал, и этот канал
          ломается, пожалуйста, _заявите об этой проблеме авторам
          каналв_, но не в проект Guix.

     Вы предупреждены!  Обозначив это, мы верим, что внешние каналы —
     это способ для вас проявлять свою свободу и вместе с тем расширять
     коллекцию пакетов Guix и делиться улучшениями, что является
     основными догматами свободного программного обеспечения
     (https://www.gnu.org/philosophy/free-sw.ru.html).  Пожалуйста,
     свяжитесь с нами по e-mail <guix-devel@gnu.org>, если вы хотите
     обсудить это.


File: guix.ru.info,  Node: Пакетные модули в поддиректории,  Next: Объявление зависимостей канала,  Prev: Создание канала,  Up: Каналы

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

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

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

   The modules must be underneath the specified directory, as the
‘directory’ changes Guile’s ‘load-path’.  For example, if
‘.guix-channel’ has ‘(directory "base")’, then a module defined as
‘(define-module (gnu packages fun))’ must be located at
‘base/gnu/packages/fun.scm’.

   Doing this allows for only parts of a repository to be used as a
channel, as Guix expects valid Guile modules when pulling.  For
instance, ‘guix deploy’ machine configuration files are not valid Guile
modules, and treating them as such would make ‘guix pull’ fail.


File: guix.ru.info,  Node: Объявление зависимостей канала,  Next: Указание авторизаций канала,  Prev: Пакетные модули в поддиректории,  Up: Каналы

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

Авторы канала могут решить расширить коллекцию пакетов пакетами, которые
поставляются другими каналами.  Они могут объявить, что их канал зависит
от других каналов, в файле метаданных ‘.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"))))

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

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


File: guix.ru.info,  Node: Указание авторизаций канала,  Next: Основной URL,  Prev: Объявление зависимостей канала,  Up: Каналы

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

Как мы видели выше, Guix гарантирует, что исходный код, который он
получает из каналов, поступает от авторизованных разработчиков.  Как
автор канала, вам необходимо указать список авторизованных разработчиков
в файле ‘.guix-authorizations’ в репозитории Git канала.  Правило
аутентификации простое: каждый коммит должен быть подписан ключом,
указанным в файле ‘.guix-authorizations’ его родительского коммита(ов)
(1) файл ‘.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 introductions answer these questions by describing the first
commit of a channel that should be authenticated.  The first time a
channel is fetched with ‘guix pull’ or ‘guix time-machine’, the command
looks up the introductory commit and verifies that it is signed by the
specified OpenPGP key.  From then on, it authenticates commits according
to the rule above.  Authentication fails if the target commit is neither
a descendant nor an ancestor of the introductory commit.

   Кроме того, ваш канал должен предоставлять все ключи 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’ в репозиторий канала.  Сделайте это
     в подписанном коммите (*note Доступ к коммитам::, чтобы узнать, как
     подписывать коммиты Git).

  3. Рекламируйте channel introduction, например, на веб-странице вашего
     канала.  Channel introduction, как мы видели выше, - это пара
     коммит/ключ, то есть коммит, который представляет
     ‘.guix-authorizations’, и отпечаток OpenPGP, использованный для его
     подписи.

   Before pushing to your public Git repository, you can run ‘guix git
authenticate’ to verify that you did sign all the commits you are about
to push with an authorized key:

     guix git authenticate COMMIT SIGNER

где COMMIT и SIGNER являются вашим channel introduction.  *Note Запуск
guix git authenticate::, подробнее.

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

   ---------- Footnotes ----------

   (1) Git коммитит из “directed acyclic graph”(DAG). У каждого коммита
может быть ноль или более родителей; “обычные” коммиты имеют одного
родителя, а “merge” коммиты имеют два родительских коммита.  Прочтите
Git for Computer Scientists
(https://eagain.net/articles/git-for-computer-scientists/), чтобы
получить больше информации.


File: guix.ru.info,  Node: Основной URL,  Next: Написание новостей канала,  Prev: Указание авторизаций канала,  Up: Каналы

6.11 Основной URL
=================

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

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

   Это позволяет ‘guix pull’ определять, pull’ит ли он код из зеркала
канала; в этом случае он предупреждает пользователя о том, что зеркало
может быть устаревшим, и отображает основной URL-адрес.  Таким образом,
пользователей нельзя обмануть, заставив их получить код с устаревшего
зеркала, которое не получает обновлений безопасности.

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


File: guix.ru.info,  Node: Написание новостей канала,  Prev: Основной URL,  Up: Каналы

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

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

   Вместо этого каналы могут предоставлять “файл новостей”; когда
пользователи канала запускают ‘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 разметку (*note
(texinfo)Overview::).  И заголовок, и тело являются списком языковых
тегов/кортежей сообщений, что позволяет комманде ‘guix pull’ отображать
новости на языке, соответствующем языку пользователя.

   Если вы хотите перевести новости, используя рабочий процесс на основе
gettext, вы можете извлечь переводимые строки с помощью ‘xgettext’
(*note (gettext)xgettext Invocation::).  Например, если вы сначала
пишете новости на английском языке, команда ниже создает PO-файл,
содержащий строки для перевода:

     xgettext -o news.po -l scheme -ken etc/news.txt

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


File: guix.ru.info,  Node: Разработка,  Next: Программный интерфейс,  Prev: Каналы,  Up: Top

7 Разработка
************

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

   The ‘guix shell’ command provides a convenient way to set up one-off
software environments, be it for development purposes or to run a
command without installing it in your profile.  The ‘guix pack’ command
allows you to create “application bundles” that can be easily
distributed to users who do not run Guix.

* Menu:

* Запуск guix shell::        Spawning one-off software environments.
* Запуск guix environment::  Настройка окружения сборки.
* Запуск guix pack::         Создание наборов программ.
* Тулчейн GCC::              Работа с языками, поддерживаемыми gcc.
* Запуск guix git authenticate::  Аутентификация Git репозиториев.


File: guix.ru.info,  Node: Запуск guix shell,  Next: Запуск guix environment,  Up: Разработка

7.1 Вызов ‘guix shell’
======================

The purpose of ‘guix shell’ is to make it easy to create one-off
software environments, without changing one’s profile.  It is typically
used to create development environments; it is also a convenient way to
run applications without “polluting” your profile.

     Примечание: The ‘guix shell’ command was recently introduced to
     supersede ‘guix environment’ (*note Запуск guix environment::).  If
     you are familiar with ‘guix environment’, you will notice that it
     is similar but also—we hope!—more convenient.

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

     guix shell [OPTIONS] [PACKAGE...]

   Иногда интерактивная сессия оболочки не нужна.  Можно вызвать
произвольную команду при указании токена ‘--’, который отделяет команду
от остальных аргументов.

   The following example creates an environment containing Python and
NumPy, building or downloading any missing package, and runs the
‘python3’ command in that environment:

     guix shell python python-numpy -- python3

   Note that it is necessary to include the main ‘python’ package in
this command even if it is already installed into your environment.
This is so that the shell environment knows to set ‘PYTHONPATH’ and
other related variables.  The shell environment cannot check the
previously installed environment, because then it would be
non-deterministic.  This is true for most libraries: their corresponding
language package should be included in the shell invocation.

     Примечание: ‘guix shell’ can be also be used as a script
     interpreter, also known as “shebang”.  Here is an example
     self-contained Python script making use of this feature:

          #!/usr/bin/env -S guix shell python python-numpy -- python3
          import numpy
          print("This is numpy", numpy.version.version)

     You may pass any ‘guix shell’ option, but there’s one caveat: the
     Linux kernel has a limit of 127 bytes on shebang length.

   Development environments can be created as in the example below,
which spawns an interactive shell containing all the dependencies and
environment variables needed to work on Inkscape:

     guix shell --development inkscape

   Exiting the shell places the user back in the original environment
before ‘guix shell’ was invoked.  The next garbage collection (*note
Вызов guix gc::) may clean up packages that were installed in the
environment and that are no longer used outside of it.

   As an added convenience, ‘guix shell’ will try to do what you mean
when it is invoked interactively without any other arguments as in:

     guix shell

   If it finds a ‘manifest.scm’ in the current working directory or any
of its parents, it uses this manifest as though it was given via
‘--manifest’.  Likewise, if it finds a ‘guix.scm’ in the same
directories, it uses it to build a development profile as though both
‘--development’ and ‘--file’ were present.  In either case, the file
will only be loaded if the directory it resides in is listed in
‘~/.config/guix/shell-authorized-directories’.  This provides an easy
way to define, share, and enter development environments.

   By default, the shell session or command runs in an _augmented_
environment, where the new packages are added to search path environment
variables such as ‘PATH’.  You can, instead, choose to create an
_isolated_ environment containing nothing but the packages you asked
for.  Passing the ‘--pure’ option clears environment variable
definitions found in the parent environment(1); passing ‘--container’
goes one step further by spawning a “container” isolated from the rest
of the system:

     guix shell --container emacs gcc-toolchain

   The command above spawns an interactive shell in a container where
nothing but ‘emacs’, ‘gcc-toolchain’, and their dependencies is
available.  The container lacks network access and shares no files other
than the current working directory with the surrounding environment.
This is useful to prevent access to system-wide resources such as
‘/usr/bin’ on foreign distros.

   This ‘--container’ option can also prove useful if you wish to run a
security-sensitive application, such as a web browser, in an isolated
environment.  For example, the command below launches Ungoogled-Chromium
in an isolated environment, which:
   • shares network access with the host
   • inherits host’s environment variables ‘DISPLAY’ and ‘XAUTHORITY’
   • has access to host’s authentication records from the ‘XAUTHORITY’
     file
   • has no information about host’s current directory

     guix shell --container --network --no-cwd ungoogled-chromium \
       --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \
       --preserve='^DISPLAY$' -- chromium

   ‘guix shell’ определяет переменную ‘GUIX_ENVIRONMENT’ в оболочке,
которую создаёт; её значением является имя файла профиля этого
окружения.  Это позволяет пользователям, скажем, определить специфичные
значения окружений разработки в ‘.bashrc’ (*note (bash)Bash Startup
Files::):

     if [ -n "$GUIX_ENVIRONMENT" ]
     then
         export PS1="\u@\h \w [dev]\$ "
     fi

... или просмотеть профиль:

     $ ls "$GUIX_ENVIRONMENT/bin"

   Доступные опции резюмированы ниже.

‘--check’
     Set up the environment and check whether the shell would clobber
     environment variables.  It’s a good idea to use this option the
     first time you run ‘guix shell’ for an interactive session to make
     sure your setup is correct.

     For example, if the shell modifies the ‘PATH’ environment variable,
     report it since you would get a different environment than what you
     asked for.

     Such problems usually indicate that the shell startup files are
     unexpectedly modifying those environment variables.  For example,
     if you are using Bash, make sure that environment variables are set
     or modified in ‘~/.bash_profile’ and _not_ in ‘~/.bashrc’—the
     former is sourced only by log-in shells.  *Note (bash)Bash Startup
     Files::, for details on Bash start-up files.

‘--development’
‘-D’
     Cause ‘guix shell’ to include in the environment the dependencies
     of the following package rather than the package itself.  This can
     be combined with other packages.  For instance, the command below
     starts an interactive shell containing the build-time dependencies
     of GNU Guile, plus Autoconf, Automake, and Libtool:

          guix shell -D guile autoconf automake libtool

‘--expression=EXPR’
‘-e EXPR’
     Создать окружение для пакета или списка пакетов, которые
     соответствуют выражению EXPR.

     Например, запуск:

          guix shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

     запускает оболочку с окружением для этого специфического варианта
     пакета PETSc.

     Запуск:

          guix shell -e '(@ (gnu) %base-packages)'

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

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

          guix shell -e '(list (@ (gnu packages bash) bash) "include")'

     *Note ‘package->development-manifest’:
     package-development-manifest, for information on how to write a
     manifest for the development environment of a package.

‘--file=FILE’
‘-f FILE’
     Create an environment containing the package or list of packages
     that the code within FILE evaluates to.

     Например, FILE может содержать определение (*note Описание
     пакетов::):

          (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 (modify-inputs (package-native-inputs gdb)
                             (prepend autoconf-2.69 automake texinfo))))

     With the file above, you can enter a development environment for
     GDB by running:

          guix shell -D -f gdb-devel.scm

‘--manifest=FILE’
‘-m FILE’
     Создать окружение для пакетов, содержащихся в объекте манифеста,
     возвращаемого кодом Scheme в файле FILE.

     Это то же, что опция с таким же именем в ‘guix package’ (*note
     ‘--manifest’: profile-manifest.) и использует такие же файлы
     манифестов.

     *Note Writing Manifests::, for information on how to write a
     manifest.  See ‘--export-manifest’ below on how to obtain a first
     manifest.

‘--export-manifest’
     Write to standard output a manifest suitable for ‘--manifest’
     corresponding to given command-line options.

     This is a way to “convert” command-line arguments into a manifest.
     For example, imagine you are tired of typing long lines and would
     like to get a manifest equivalent to this command line:

          guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

     Just add ‘--export-manifest’ to the command line above:

          guix shell --export-manifest \
            -D guile git emacs emacs-geiser emacs-geiser-guile

     ...  and you get a manifest along these lines:

          (concatenate-manifests
            (list (specifications->manifest
                    (list "git"
                          "emacs"
                          "emacs-geiser"
                          "emacs-geiser-guile"))
                  (package->development-manifest
                    (specification->package "guile"))))

     You can store it into a file, say ‘manifest.scm’, and from there
     pass it to ‘guix shell’ or indeed pretty much any ‘guix’ command:

          guix shell -m manifest.scm

     Voilà, you’ve converted a long command line into a manifest!  That
     conversion process honors package transformation options (*note
     Параметры преобразования пакета::) so it should be lossless.

‘--profile=PROFILE’
‘-p PROFILE’
     Создает окружение, содержащее пакеты, установленные в PROFILE.
     Используйте ‘guix package’ (*note Вызов guix package::) для
     создания и управления профилями.

‘--pure’
     Сброс существующих переменных окружения при сборке нового
     окружения, кроме обозначенных в опции ‘--preserve’ (смотрите ниже).
     Эффект этой опции — создание окружения, в котором пути поиска
     содержат только входные данные пакета.

‘--preserve=REGEXP’
‘-E REGEXP’
     При использовании вместе с ‘--pure’, оставить содержимое переменных
     окружения, соответствующих выражению REGEXP — другими словами,
     включить их в "белый список" переменных окружения, которые не
     должны обнуляться.  Эту опцию можно повторять несколько раз.

          guix shell --pure --preserve=^SLURM openmpi ... \
            -- mpirun ...

     Этот пример запускает ‘mpirun’ в контексте, в котором определены
     только следующие переменные окружения: ‘PATH’, переменные
     окружения, чьи имена начинаются с ‘SLURM’, а также обычные
     "дорогие" переменные (‘HOME’, ‘USER’, и т.д.).

‘--search-paths’
     Отобразить определения переменных окружения, которые составляют
     окружение.

‘--system=SYSTEM’
‘-s SYSTEM’
     Попытаться собрать систему SYSTEM, то есть ‘i686-linux’.

‘--container’
‘-C’
     Запустить COMMAND в изолированном контейнере.  Текущая рабочая
     директория за пределами контейнера отображается внутри контейнера.
     В дополнение, если это не переопределено опцией ‘--user’, тогда
     настраивается фиктивная домашняя директория, которая совпадает с
     домашней директорией текущего пользователя, а также соответствующий
     файл ‘/etc/passwd’.

     Порождаемый процесс снаружи предстаёт как запущенный от текущего
     пользователя.  Внутри контейнера он имеет такие же UID и GID, что и
     текущий пользователь, если не обозначена ‘--user’ (смотрите ниже).

‘--network’
‘-N’
     Разделять пространство сетевых имён контейнера с хостящей системой.
     Контейнеры, созданные без этого флага, могут только иметь доступ к
     петлевому устройству.

‘--link-profile’
‘-P’
     Связать профиль окружения контейнера с ‘~/.guix-profile’ внутри
     контейнера.  Это эквивалент запуска команды ‘ln -s
     $GUIX_ENVIRONMENT ~/.guix-profile’ внутри контейнера.  Связывание
     завершится ошибкой и отменит создание окружения, если директория
     уже существует, что, конечно, будет происходить, если ‘guix shell’
     вызвана в домашней директории пользователя.

     Определённые пакеты сконфигурированы, чтобы смотреть
     конфигурационные файлы и данные в ‘~/.guix-profile’;(2)
     ‘--link-profile’ позволяет этим программам вести себя ожидаемо
     внутри окружения.

‘--user=USER’
‘-u USER’
     Использовать в контейнере имя пользователя USER вместо текущего
     пользователя.  Созданная внутри контейнера запись ‘/etc/passwd’
     будет содержать имя USER, домашняя директория будет ‘/home/USER’,
     но не будут копированы пользовательские данные GECOS. Более того,
     внутри контейнера UID и GID будут 1000.  USER не обязательно должен
     существовать в системе.

     В дополнение, любой разделяемый или расширяемый путь (смотрите
     ‘--share’ и ‘--expose’ соответственно), чьи цели находятся в
     домашней директории пользователя, будут отображены соответственно в
     ‘/home/USER’; это включает автоматическое отображение текущей
     рабочей директории.

          # will expose paths as /home/foo/wd, /home/foo/test, and /home/foo/target
          cd $HOME/wd
          guix shell --container --user=foo \
               --expose=$HOME/test \
               --expose=/tmp/target=$HOME/target

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

‘--no-cwd’
     Для контейнеров стандартным поведением является разделение текущего
     рабочего каталога с изолированным контейнером и немедленное
     переключение на этот каталог в контейнере.  Если это нежелательно,
     ‘--no-cwd’ приведет к автоматическому доступу к текущему рабочему
     каталогу _not_, который изменится на домашний каталог пользователя
     в контейнере.  Смотрите также ‘--user’.

‘--writable-root’
     When using ‘--container’, this option makes the root file system
     writable (it is read-only by default).

‘--expose=SOURCE[=TARGET]’
‘--share=SOURCE[=TARGET]’
     Расширить файловую систему контейнера источником SOURCE из хостящей
     системы в качестве файловой системы только для чтения с целью
     TARGET внутри контейнера.  Если цель TARGET не задана, источник
     SOURCE используется как целевая точка монтирования в контейнере.

     Пример ниже порождает Guile REPL в контейнере, в котором домашняя
     директория пользователя доступна только для чтения через директорию
     ‘/exchange’:

          guix shell --container --expose=$HOME=/exchange guile -- guile

‘--symlink=SPEC’
‘-S SPEC’
     For containers, create the symbolic links specified by SPEC, as
     documented in *note pack-symlink-option::.

‘--emulate-fhs’
‘-F’
     When used with ‘--container’, emulate a Filesystem Hierarchy
     Standard (FHS) (https://refspecs.linuxfoundation.org/fhs.shtml)
     configuration within the container, providing ‘/bin’, ‘/lib’, and
     other directories and files specified by the FHS.

     As Guix deviates from the FHS specification, this option sets up
     the container to more closely mimic that of other GNU/Linux
     distributions.  This is useful for reproducing other development
     environments, testing, and using programs which expect the FHS
     specification to be followed.  With this option, the container will
     include a version of glibc that will read ‘/etc/ld.so.cache’ within
     the container for the shared library cache (contrary to glibc in
     regular Guix usage) and set up the expected FHS directories:
     ‘/bin’, ‘/etc’, ‘/lib’, and ‘/usr’ from the container’s profile.

‘--nesting’
‘-W’
     When used with ‘--container’, provide Guix _inside_ the container
     and arrange so that it can interact with the build daemon that runs
     outside the container.  This is useful if you want, within your
     isolated container, to create other containers, as in this sample
     session:

          $ guix shell -CW coreutils
          [env]$ guix shell -C guile -- guile -c '(display "hello!\n")'
          hello!
          [env]$ exit

     The session above starts a container with ‘coreutils’ programs
     available in ‘PATH’.  From there, we spawn ‘guix shell’ to create a
     _nested_ container that provides nothing but Guile.

     Another example is evaluating a ‘guix.scm’ file that is untrusted,
     as shown here:

          guix shell -CW -- guix build -f guix.scm

     The ‘guix build’ command as executed above can only access the
     current directory.

     Under the hood, the ‘-W’ option does several things:

        • отобразит сокет демона (по умолчанию
          ‘/var/guix/daemon-socket/socket’) внутри контейнера;
        • map the whole store (by default ‘/gnu/store’) inside the
          container such that store items made available by nested
          ‘guix’ invocations are visible;
        • add the currently-used ‘guix’ command to the profile in the
          container, such that ‘guix describe’ returns the same state
          inside and outside the container;
        • share the cache (by default ‘~/.cache/guix’) with the host, to
          speed up operations such as ‘guix time-machine’ and ‘guix
          shell’.

‘--rebuild-cache’
     In most cases, ‘guix shell’ caches the environment so that
     subsequent uses are instantaneous.  Least-recently used cache
     entries are periodically removed.  The cache is also invalidated,
     when using ‘--file’ or ‘--manifest’, anytime the corresponding file
     is modified.

     The ‘--rebuild-cache’ forces the cached environment to be
     refreshed.  This is useful when using ‘--file’ or ‘--manifest’ and
     the ‘guix.scm’ or ‘manifest.scm’ file has external dependencies, or
     if its behavior depends, say, on environment variables.

‘--root=FILE’
‘-r FILE’
     Создать символическую ссылку FILE на профиль этого окружения и
     зарегистрировать её как корень сборщика мусора.

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

     When this option is omitted, ‘guix shell’ caches profiles so that
     subsequent uses of the same environment are instantaneous—this is
     comparable to using ‘--root’ except that ‘guix shell’ takes care of
     periodically removing the least-recently used garbage collector
     roots.

     In some cases, ‘guix shell’ does not cache profiles—e.g., if
     transformation options such as ‘--with-latest’ are used.  In those
     cases, the environment is protected from garbage collection only
     for the duration of the ‘guix shell’ session.  This means that next
     time you recreate the same environment, you could have to rebuild
     or re-download packages.

     *Note Вызов guix gc::, for more on GC roots.

   ‘guix shell’ также поддерживает все обычные опции сборки, которые
поддерживает команда ‘guix build’ (*note Стандартные параметры
сборки::), а также опции трансформации пакета (*note Параметры
преобразования пакета::).

   ---------- Footnotes ----------

   (1) Be sure to use the ‘--check’ option the first time you use ‘guix
shell’ interactively to make sure the shell does not undo the effect of
‘--pure’.

   (2) Например, пакет ‘fontconfig’ просматривает
‘~/.guix-profile/share/fonts’ для дополнительных шрифтов.


File: guix.ru.info,  Node: Запуск guix environment,  Next: Запуск guix pack,  Prev: Запуск guix shell,  Up: Разработка

7.2 Вызов ‘guix environment’
============================

The purpose of ‘guix environment’ is to assist in creating development
environments.

     Deprecation warning: The ‘guix environment’ command is deprecated
     in favor of ‘guix shell’, which performs similar functions but is
     more convenient to use.  *Note Запуск guix shell::.

     Being deprecated, ‘guix environment’ is slated for eventual
     removal, but the Guix project is committed to keeping it until May
     1st, 2023.  Please get in touch with us at <guix-devel@gnu.org> if
     you would like to discuss it.

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

     guix environment OPTIONS PACKAGE...

   Следующий пример порождает новую оболочку, установленную для
разработки GNU Guile:

     guix environment guile

   Если необходимые зависимости еще не собраны, ‘guix environment’
автоматически построит их.  Среда новой оболочки - это расширенная
версия среды, в которой была запущена ‘guix environment’.  Она содержит
необходимые пути поиска для сборки данного пакета, добавленные к
существующим переменным среды.  Чтобы создать “чистую” среду, в которой
исходные переменные среды не были установлены, используйте параметр
‘--pure’ (1).

   Выход из окружения Guix аналогичен выходу из оболочки и возвращает
пользователя в старое окружение до вызова ‘guix environment’.  Следующая
сборка мусора (*note Вызов guix gc::) очистит пакеты, которые были
установлены в окружении и больше не используются за ее пределами.

   ‘guix environment’ определяет переменную ‘GUIX_ENVIRONMENT’ в
оболочке, которую создаёт; её значением является имя файла профиля этого
окружения.  Это позволяет пользователям, скажем, определить специфичные
значения окружений разработки в ‘.bashrc’ (*note (bash)Bash Startup
Files::):

     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

   In other situations, it is more convenient to specify the list of
packages needed in the environment.  For example, the following command
runs ‘python’ from an environment containing Python 3 and NumPy:

     guix environment --ad-hoc python-numpy python -- python3

   Более того, возможно, вам потребуются зависимости пакета, а также
некоторые дополнительные пакеты, которые не являются зависимостями
процесса сборки или процесса исполнения (работы), но важны при
разработке.  Для этого и указан флаш ‘--ad-hoc’.  Пакеты, обозначенные
до ‘--ad-hoc’ интерпретируются как пакеты, чьи зависимости будут
добавлены в окружение.  Пакеты, которые обозначены после ‘--ad-hoc’,
интерпретируются как пакеты, которые будут добавлены в окружение
непосредственно.  Например, следующая команда создаёт окружение
разработки Guix, которая в дополнение включает Git и strace:

     guix environment guix --ad-hoc git strace

   Иногда возникает необходимость изолировать окружение настолько,
насколькоо возможно, для максимальной чистоты и воспроизводимости.  В
частности, при использовании Guix на дистрибутиве, отличном от системы
Guix, желательно предотвращать доступ из окружения разработки к
‘/usr/bin’ и другим ресурсам системы.  Например, следующая команда
порождает Guile REPL в "контейнере", в котором монтированы только склад
и текущая рабочая директория:

     guix environment --ad-hoc --container guile -- guile

     Примечание: Опция ‘--container’ требует Linux-libre 3.19 или новее.

   Другой типичный вариант использования контейнеров - запуск
приложений, чувствительных к безопасности, таких как веб-браузер.  Чтобы
запустить Eolie, мы должны предоставить доступ к некоторым файлам и
каталогам; мы используем ‘nss-certs’ и предоставляем ‘/etc /ssl /certs/’
для аутентификации HTTPS; наконец, мы сохраняем переменную среды
‘DISPLAY’, поскольку контейнерные графические приложения не будут
отображаться без нее.

     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

   Доступные опции резюмированы ниже.

‘--check’
     Set up the environment and check whether the shell would clobber
     environment variables.  *Note ‘--check’: Запуск guix shell, for
     more info.

‘--root=FILE’
‘-r FILE’
     Создать символическую ссылку FILE на профиль этого окружения и
     зарегистрировать её как корень сборщика мусора.

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

     Если эта опция пропущена, окружеие защищено от сборщика мусора
     только на время сессии ‘guix environment’.  Это означает, что в
     следующий раз, когда вы создадите такое же окружение, вам
     потребуется пересобирать и скачивать пакеты заново.  *Note Вызов
     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 может содержать определение (*note Описание
     пакетов::):

          (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 (modify-inputs (package-native-inputs gdb)
                             (prepend autoconf-2.69 automake texinfo))))

‘--manifest=FILE’
‘-m FILE’
     Создать окружение для пакетов, содержащихся в объекте манифеста,
     возвращаемого кодом Scheme в файле FILE.

     Это то же, что опция с таким же именем в ‘guix package’ (*note
     ‘--manifest’: profile-manifest.) и использует такие же файлы
     манифестов.

     *Note ‘guix shell --export-manifest’: shell-export-manifest, for
     information on how to “convert” command-line options into a
     manifest.

‘--ad-hoc’
     Включить все указанные пакеты в результирующее окружение, если бы
     целевой (лат.  ad hoc) пакет имел бы их как входные данные.  Эта
     опция полезна для быстрого создания окружения без необходимости
     писать выражение типа пакет, содержащее желаемые входные данные.

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

          guix environment --ad-hoc guile guile-sdl -- guile

     запускает ‘guile’ в окружении, в котором доступны Guile и
     Guile-SDL.

     Отметим, что этот пример явно запрашивает выходы ‘guile’ и
     ‘guile-sdl’ по умолчанию, но возможно запросить специфичный выход,
     то есть ‘glib:bin’ запрашивает выход ‘bin’ из ‘glib’ (*note Пакеты
     со множественным выходом::).

     Эта опция может сочетаться с поведением по умолчанию ‘guix
     environment’.  Пакеты, которые появляются до ‘--ad-hoc’
     интерпретируются как пакеты, чьи зависимости будут добавлены в
     окружение (поведение по умолчанию).  Пакеты, которые появляются
     после этой опции, интерпретируются как пакеты, которые будут
     добавлены в окружение непосредственно.

‘--profile=PROFILE’
‘-p PROFILE’
     Создает окружение, содержащее пакеты, установленные в PROFILE.
     Используйте ‘guix package’ (*note Вызов guix package::) для
     создания и управления профилями.

‘--pure’
     Сброс существующих переменных окружения при сборке нового
     окружения, кроме обозначенных в опции ‘--preserve’ (смотрите ниже).
     Эффект этой опции — создание окружения, в котором пути поиска
     содержат только входные данные пакета.

‘--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’
     Запустить COMMAND в изолированном контейнере.  Текущая рабочая
     директория за пределами контейнера отображается внутри контейнера.
     В дополнение, если это не переопределено опцией ‘--user’, тогда
     настраивается фиктивная домашняя директория, которая совпадает с
     домашней директорией текущего пользователя, а также соответствующий
     файл ‘/etc/passwd’.

     Порождаемый процесс снаружи предстаёт как запущенный от текущего
     пользователя.  Внутри контейнера он имеет такие же UID и GID, что и
     текущий пользователь, если не обозначена ‘--user’ (смотрите ниже).

‘--network’
‘-N’
     Разделять пространство сетевых имён контейнера с хостящей системой.
     Контейнеры, созданные без этого флага, могут только иметь доступ к
     петлевому устройству.

‘--link-profile’
‘-P’
     Связать профиль окружения контейнера с ‘~/.guix-profile’ внутри
     контейнера.  Это эквивалент запуска команды ‘ln -s
     $GUIX_ENVIRONMENT ~/.guix-profile’ внутри контейнера.  Связывание
     завершится ошибкой и отменит создание окружения, если директория
     уже существует, что, конечно, будет происходить, если ‘guix
     environment’ вызвана в домашней директории пользователя.

     Определённые пакеты сконфигурированы, чтобы смотреть
     конфигурационные файлы и данные в ‘~/.guix-profile’;(2)
     ‘--link-profile’ позволяет этим программам вести себя ожидаемо
     внутри окружения.

‘--user=USER’
‘-u USER’
     Использовать в контейнере имя пользователя USER вместо текущего
     пользователя.  Созданная внутри контейнера запись ‘/etc/passwd’
     будет содержать имя USER, домашняя директория будет ‘/home/USER’,
     но не будут копированы пользовательские данные GECOS. Более того,
     внутри контейнера UID и GID будут 1000.  USER не обязательно должен
     существовать в системе.

     В дополнение, любой разделяемый или расширяемый путь (смотрите
     ‘--share’ и ‘--expose’ соответственно), чьи цели находятся в
     домашней директории пользователя, будут отображены соответственно в
     ‘/home/USER’; это включает автоматическое отображение текущей
     рабочей директории.

          # 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’
     Для контейнеров стандартным поведением является разделение текущего
     рабочего каталога с изолированным контейнером и немедленное
     переключение на этот каталог в контейнере.  Если это нежелательно,
     ‘--no-cwd’ приведет к автоматическому доступу к текущему рабочему
     каталогу _not_, который изменится на домашний каталог пользователя
     в контейнере.  Смотрите также ‘--user’.

‘--expose=SOURCE[=TARGET]’
‘--share=SOURCE[=TARGET]’
     Расширить файловую систему контейнера источником SOURCE из хостящей
     системы в качестве файловой системы только для чтения с целью
     TARGET внутри контейнера.  Если цель TARGET не задана, источник
     SOURCE используется как целевая точка монтирования в контейнере.

     Пример ниже порождает Guile REPL в контейнере, в котором домашняя
     директория пользователя доступна только для чтения через директорию
     ‘/exchange’:

          guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile

‘--emulate-fhs’
‘-F’
     For containers, emulate a Filesystem Hierarchy Standard (FHS)
     configuration within the container, see the official specification
     (https://refspecs.linuxfoundation.org/fhs.shtml).  As Guix deviates
     from the FHS specification, this option sets up the container to
     more closely mimic that of other GNU/Linux distributions.  This is
     useful for reproducing other development environments, testing, and
     using programs which expect the FHS specification to be followed.
     With this option, the container will include a version of ‘glibc’
     which will read ‘/etc/ld.so.cache’ within the container for the
     shared library cache (contrary to ‘glibc’ in regular Guix usage)
     and set up the expected FHS directories: ‘/bin’, ‘/etc’, ‘/lib’,
     and ‘/usr’ from the container’s profile.

   ‘guix environment’ также поддерживает все обычные опции сборки,
которые поддерживает команда ‘guix build’ (*note Стандартные параметры
сборки::), а также опции трансформации пакета (*note Параметры
преобразования пакета::).

   ---------- Footnotes ----------

   (1) Пользователи иногда ошибочно изменяют переменные среды, такие как
‘PATH’, в своем ‘~/.bashrc’ файле.  Как следствие, когда ‘guix
environment’ запускает его, Bash может читать ‘~/.bashrc’, тем самым
вводя “примеси” в эти переменные среды.  Ошибочно определять такие
переменные среды в ‘.bashrc’; вместо этого они должны быть определены в
‘.bash_profile’, источником которого являются только оболочки входа в
систему.  *Note (bash)Bash Startup Files::, для получения подробной
информации о файлах запуска Bash.

   (2) Например, пакет ‘fontconfig’ просматривает
‘~/.guix-profile/share/fonts’ для дополнительных шрифтов.


File: guix.ru.info,  Node: Запуск guix pack,  Next: Тулчейн GCC,  Prev: Запуск guix environment,  Up: Разработка

7.3 Вызов ‘guix pack’
=====================

Иногда бывает необходимо передать программу людям, которые (ещё!)  не
являются счастливыми обладателями Guix.  Вы могли бы им рекомендовать
заустить ‘guix package -i SOMETHING’, но в данном случае это не
подхлдит.  Тогда ‘guix pack’ решает вопрос.

     Примечание: Если вы ищете способ обмена бинарниками между машинами,
     работающими с Guix, *note Запуск guix copy::, *note Запуск guix
     publish:: и *note Вызов 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 (*note Бинарная установка::).

   Пользователи этого пакета должны запускать
‘/gnu/store/...-profile/bin/guile’ для запуска Guile, что может быть не
удобно.  Чтобы исправить это, можно создать, например, символическую
ссылку ‘/opt/gnu/bin’ на профиль:

     guix pack -S /opt/gnu/bin=bin guile emacs geiser

Так пользователи смогут благополучно напечатать ‘/opt/gnu/bin/guile’, и
всё хорошо.

   Что если получатель вашего пакета не имеет привилегий root на своей
машине, и поэтому не может распаковать его в корне файловой системы?  В
таком случае вам стоит использовать опцию ‘--relocatable’ (смотрите
ниже).  Эта опция производит “перемещаемые бинарники”, в том плане, что
они могут размещаться где угодно в иерархии файловой системы: в примере
выше пользователи могут распаковать ваш архив в свои домашние директории
и напрямую запустить ‘./opt/gnu/bin/guile’.

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

     guix pack -f docker guile emacs geiser

Результатом будет архив, который можно передать команде ‘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
(https://docs.docker.com/engine/reference/commandline/load/) for more
information.

   Ещё одна опция производит образ SquashFS следующей командой:

     guix pack -f squashfs guile emacs geiser

Результатом будет образ файловой системы SquashFS, который может
непосредственно монтироваться как образ, содержащий контейнер файловой
системы, с помощью контейнерного окружения Singularity
(https://www.sylabs.io/docs/), используя команды типа ‘singularity
shell’ или ‘singularity exec’.

   Another format internally based on SquashFS is AppImage
(https://appimage.org/).  An AppImage file can be created and executed
without any special privileges:

     file=$(guix pack -f appimage --entry-point=bin/guile guile)
     $file --help

   Несколько опций командной строки позволяют вам переделывать ваш
пакет:

‘--format=FORMAT’
‘-f FORMAT’
     Произвести пакет в указанном формате FORMAT.

     Возможные форматы:

     ‘tarball’
          Это формат по умолчанию.  Он производит архив tarball,
          содержащий все заданные бинарники и символические ссылки.

     ‘docker’
          This produces a tarball that follows the Docker Image
          Specification
          (https://github.com/docker/docker/blob/master/image/spec/v1.2.md).
          By default, 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.
          Alternatively, the “repository name” can also be configured
          via the ‘--image-tag’ option.  Refer to ‘--help-docker-format’
          for more information on such advanced options.

     ‘squashfs’
          Это создает образ SquashFS, содержащий все указанные двоичные
          файлы и символические ссылки, а также пустые точки
          монтирования для виртуальных файловых систем, таких как
          procfs.

               Примечание: Singularity _требует_, чтобы вы указали ‘/bin
               /sh’ в образе.  По этой причине ‘guix pack -f squashfs’
               всегда подразумевает ‘-S /bin=bin’.  Таким образом, вызов
               ‘guix pack’ всегда должен начинаться с чего-то вроде:

                    guix pack -f squashfs guile emacs geiser

               Если вы забудете пакет ‘bash’ (или аналогичный),
               ‘singularity run’ и ‘singularity exec’ выдаст бесполезное
               сообщение “нет такого файла или каталога”.

     ‘deb’
          This produces a Debian archive (a package with the ‘.deb’ file
          extension) containing all the specified binaries and symbolic
          links, that can be installed on top of any dpkg-based
          GNU(/Linux) distribution.  Advanced options can be revealed
          via the ‘--help-deb-format’ option.  They allow embedding
          control files for more fine-grained control, such as
          activating specific triggers or providing a maintainer
          configure script to run arbitrary setup code upon
          installation.

               guix pack -f deb -C xz -S /usr/bin/hello=bin/hello hello

               Примечание: Because archives produced with ‘guix pack’
               contain a collection of store items and because each
               ‘dpkg’ package must not have conflicting files, in
               practice that means you likely won’t be able to install
               more than one such archive on a given system.  You can
               nonetheless pack as many Guix packages as you want in one
               such archive.

               Предупреждение: ‘dpkg’ will assume ownership of any files
               contained in the pack that it does _not_ know about.  It
               is unwise to install Guix-produced ‘.deb’ files on a
               system where ‘/gnu/store’ is shared by other software,
               such as a Guix installation or other, non-deb packs.

     ‘rpm’
          This produces an RPM archive (a package with the ‘.rpm’ file
          extension) containing all the specified binaries and symbolic
          links, that can be installed on top of any RPM-based GNU/Linux
          distribution.  The RPM format embeds checksums for every file
          it contains, which the ‘rpm’ command uses to validate the
          integrity of the archive.

          Advanced RPM-related options are revealed via the
          ‘--help-rpm-format’ option.  These options allow embedding
          maintainer scripts that can run before or after the
          installation of the RPM archive, for example.

          The RPM format supports relocatable packages via the
          ‘--prefix’ option of the ‘rpm’ command, which can be handy to
          install an RPM package to a specific prefix.

               guix pack -f rpm -R -C xz -S /usr/bin/hello=bin/hello hello

               sudo rpm --install --prefix=/opt /gnu/store/...-hello.rpm

               Примечание: Contrary to Debian packages, conflicting but
               _identical_ files in RPM packages can be installed
               simultaneously, which means multiple ‘guix pack’-produced
               RPM packages can usually be installed side by side
               without any problem.

               Предупреждение: ‘rpm’ assumes ownership of any files
               contained in the pack, which means it will remove
               ‘/gnu/store’ upon uninstalling a Guix-generated RPM
               package, unless the RPM package was installed with the
               ‘--prefix’ option of the ‘rpm’ command.  It is unwise to
               install Guix-produced ‘.rpm’ packages on a system where
               ‘/gnu/store’ is shared by other software, such as a Guix
               installation or other, non-rpm packs.

     ‘appimage’
          This produces an AppImage file (https://appimage.org/) with
          the ‘.AppImage’ extension.  AppImage is a SquashFS volume
          prefixed with a runtime that mounts the SquashFS file system
          and executes the binary provided with ‘--entry-point’.  This
          results in a self-contained archive that bundles the software
          and all its requirements into a single file.  When the file is
          made executable it runs the packaged software.

               guix pack -f appimage --entry-point=bin/vlc vlc

          The runtime used by AppImages invokes the ‘fusermount3’
          command to mount the image quickly.  If that command is
          unavailable, the AppImage fails to run, but it can still be
          started by passing the ‘--appimage-extract-and-run’ flag.

               Предупреждение: When building an AppImage, always _pass_
               the ‘--relocatable’ option (or ‘-R’, or ‘-RR’) to make
               sure the image can be used on systems where Guix is not
               installed.  A warning is printed when this option is not
               used.

               guix pack -f appimage --entry-point=bin/hello --relocatable hello

               Примечание: The resulting AppImage does not conform to
               the complete standard as it currently does not contain a
               ‘.DirIcon’ file.  This does not impact functionality of
               the AppImage itself, but possibly that of software used
               to manage AppImages.

               Примечание: As the generated AppImage packages the
               complete dependency graph, it will be larger than
               comparable AppImage files found online, which depend on
               host system libraries.

‘--relocatable’
‘-R’
     Создавать “relocatable binaries” — то есть двоичные файлы, которые
     можно разместить в любом месте иерархии файловой системы и
     запускать оттуда.

     Когда эта опция передается один раз, конечные двоичные файлы
     требуют поддержки “user namespaces” в ядре Linux; при передаче
     _дважды_(1), 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
               (https://proot-me.github.io/) обеспечивает необходимую
               поддержку виртуализации файловой системы.  Это
               достигается с помощью системного вызова ‘ptrace’ в
               запущенной программе.  Преимущество этого подхода
               заключается в том, что это не требует специальной
               поддержки ядра, но это требует дополнительных затрат
               времени выполнения каждый раз, когда выполняется
               системный вызов.

          ‘fakechroot’
               Запустить Fakechroot.  Fakechroot
               (https://github.com/dex4er/fakechroot/) виртуализирует
               доступ к файловой системе путем перехвата вызовов функций
               библиотеки C, таких как ‘open’, ‘stat’, ‘exec’ и т.п.  В
               отличие от PRoot, накладных расходов очень мало.  Однако
               это не всегда работает: например, некоторые обращения к
               файловой системе, сделанные из библиотеки C, не
               перехватываются, а обращения к файловой системе,
               сделанные через прямые системные вызовы, также не
               перехватываются, что приводит к нестабильному поведению.

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

‘--commit=COMMIT’
     Используйте COMMAND в качестве “точки входа” конечного пакета, если
     формат пакета поддерживает это — в настоящее время ‘docker’,
     ‘appimage’ и ‘squashfs’ (Singularity) поддерживают это.  COMMAND
     должна относиться к профилю, содержащемуся в пакете.

     Точка входа указывает команду, которую по умолчанию автоматически
     запускают такие инструменты, как ‘docker run’ или ‘singularity
     run’.  Например, вы можете сделать:

          guix pack -f docker guile emacs geiser

     Полученный пакет может быть легко импортирован, и запущен через
     ‘docker run’ без дополнительных аргументов, пораждая ‘bin/guile’:

          docker load -i pack.tar.gz
          docker run IMAGE-ID

‘--entry-point-argument=COMMAND’
‘-A COMMAND’
     Use COMMAND as an argument to “entry point” of the resulting pack.
     This option is only valid in conjunction with ‘--entry-point’ and
     can appear multiple times on the command line.

          guix pack -f docker --entry-point=bin/guile --entry-point-argument="--help" guile

‘--max-layers=n’
     Specifies the maximum number of Docker image layers allowed when
     building an image.

          guix pack -f docker --max-layers=100 guile

     This option allows you to limit the number of layers in a Docker
     image.  Docker images are comprised of multiple layers, and each
     layer adds to the overall size and complexity of the image.  By
     setting a maximum number of layers, you can control the following
     effects:

        • Disk Usage: Increasing the number of layers can help optimize
          the disk space required to store multiple images built with a
          similar package graph.

        • Pulling: When transferring images between different nodes or
          systems, having more layers can reduce the time required to
          pull the image.

‘--expression=EXPR’
‘-e EXPR’
     Процедура, при выполнении которой возвращается пакет.

     Это то же, что опция с таким же именем в ‘guix package’ (*note
     ‘--manifest’: profile-manifest.) и использует такие же файлы
     манифестов.

‘--file=FILE’
     Build a pack containing the package or other object the code within
     FILE evaluates to.

     This has the same purpose as the same-named option in ‘guix build’
     (*note ‘--file’ in ‘guix build’: Дополнительные параметры сборки.),
     but it has no shorthand, because ‘-f’ already means ‘--format’.

‘--manifest=FILE’
‘-m FILE’
     Использовать пакеты, содержащиеся в объекте манифеста, возвращенном
     кодом Scheme в FILE.  Эта опция может быть указана несколько раз, и
     в этом случае манифесты объединяются.

     Она служит для того же, что и одноименная опция в ‘guix package’
     (*note ‘--manifest’: profile-manifest.) и использует те же файлы
     манифеста.  Она позволяет вам один раз определить набор пакетов и
     использовать его как для создания профилей, так и для создания
     архивов для использования на машинах, на которых не установлен
     Guix.  Обратите внимание, что вы можете указать _либо_ файл
     манифеста _либо_ список пакетов, но не то и другое вместе.

     *Note Writing Manifests::, for information on how to write a
     manifest.  *Note ‘guix shell --export-manifest’:
     shell-export-manifest, for information on how to “convert”
     command-line options into a manifest.

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

‘--target=TRIPLET’
     Cross-сборка для TRIPLET, который должен быть допустимым GNU
     triplet, например ‘\ "aarch64-linux-gnu\"’ (*note GNU configuration
     triplets: (autoconf)Specifying target triplets.).

‘--compression=TOOL’
‘-C TOOL’
     Архивировать логи сборки методом TYPE.  Это один из: ‘gzip’,
     ‘bzip2’ или ‘none’.

‘--symlink=SPEC’
‘-S SPEC’
     Добавить в пакет символические ссылки, указанные в SPEC.  Эта опция
     может быть указана несколько раз.

     SPEC имеет вид ‘SOURCE=TARGET’, где SOURCE - это символическая
     ссылка, которая будет создана, а TARGET - это цель символьной
     ссылки.

     Например, ‘-S /opt/gnu/bin=bin’ создает символическую ссылку
     ‘/opt/gnu/bin’, указывающую на подкаталог ‘bin’ профиля.

‘--save-provenance’
     Сохранить информацию о происхождении пакетов, переданных в
     командной строке.  Информация о происхождении включает в себя URL и
     фиксацию используемых каналов (*note Каналы::).

     Информация о происхождении сохраняется в файле
     ‘/gnu/store/...-profile/manifest’ в пакете вместе с обычными
     метаданными пакета - названием и версией каждого пакета, их
     propagated inputs и т.п.  Это полезная информация для получателя
     pack, который исходя из нее знает, как (предположительно) был
     собран pack.

     Этот параметр не включен по умолчанию, поскольку, как и временные
     метки, информация о происхождении не влияет на процесс сборки.
     Другими словами, существует бесконечное количество URL-адресов
     каналов и ID коммитов, которые могут привести к одному и тому же
     pack.  Таким образом, запись таких “тихих” метаданных в output
     потенциально нарушает свойство побитовой воспроизводимости.

‘--root=FILE’
‘-r FILE’
     Создать символическую ссылку FILE на профиль этого окружения и
     зарегистрировать её как корень сборщика мусора.

‘--localstatedir’
‘--profile-name=NAME’
     Включите в конечный пакет “локальный каталог состояния”,
     ‘/var/guix’ и, в частности, профиль
     ‘/var/guix/profiles/per-user/root/NAME’ — по умолчанию NAME - это
     ‘guix-profile’, что соответствует ‘~root/.guix-profile’.

     ‘/var/guix’ содержит базу данных store (*note Хранилище::), а также
     корни сборщика мусора (*note Вызов guix gc::).  Предоставление ее в
     pack означает, что store является “полным” и управляемым Guix;
     отсутствие в pack означает, что store “мертв”: пакеты нельзя
     добавить в него или удалить из него после извлечения pack.

     Одним из вариантов использования является включающий себя двоичный
     архив Guix (*note Бинарная установка::).

‘--derivation’
‘-d’
     Выведите имя derivation, которая создает pack.

‘--bootstrap’
     Использовать bootstrap бинарники для сборки пакета.  Эта опция
     полезна только разработчикам Guix.

   Кроме того, ‘guix pack’ поддерживает все стандартные параметры сборки
(*note Стандартные параметры сборки::) и все параметры преобразования
пакетов (*note Параметры преобразования пакета::).

   ---------- Footnotes ----------

   (1) Вот трюк, чтобы запомнить его: ‘-RR’, который добавляет поддержку
PRoot, можно рассматривать как сокращение от “Really Relocatable”.
Удобно, не правда ли?


File: guix.ru.info,  Node: Тулчейн GCC,  Next: Запуск guix git authenticate,  Prev: Запуск guix pack,  Up: Разработка

7.4 Тулчейн GCC
===============

Guix предлагает индивидуальные пакеты компиляторов, как например, ‘gcc’.
Но если вам необходим полный набор инструментов (тулчейн) для компиляции
и линковки исходного кода, тогда то, что вам действительно нужно, — это
пакет ‘gcc-toolchain’.  Этот пакет предоставляет полный тулчейн GCC для
разработки C/C++, включая сам GCC, библиотеку GNU C (заголовки и
бинарники, а также отладочные символы в выходе ‘debug’), Binutils и
набор линковщика.

   Цель оболочки — проверять опции ‘-L’ и ‘-l’, направленные линковщику,
и соответствующие аргументы ‘-rpath’, и вызывать соответствующий
линковщик с этим новым набором аргументов.  Вы можете указать оболочке
отклонять линковку с библиотеками, находящимися не на складе, установив
переменную окружения ‘GUIX_LD_WRAPPER_ALLOW_IMPURITIES’ в значение ‘no’.

   Пакет ‘gfortran-toolchain’ предоставляет полный набор инструментов
GCC для разработки Fortran.  Для других языков используйте ‘guix search
gcc toolchain’ (*note Invoking guix package: guix-search.).


File: guix.ru.info,  Node: Запуск guix git authenticate,  Prev: Тулчейн GCC,  Up: Разработка

7.5 Вызов ‘guix package’
========================

Команда ‘guix git Authenticate’ аутентифицирует проверку Git по тому же
правилу, что и для каналов (*note channel authentication:
channel-authentication.).  То есть, начиная с данного коммита, он
гарантирует, что все последующие коммиты подписаны ключом OpenPGP,
отпечаток которого указан в файле ‘.guix-authorizations’ его
родительского коммита(ов).

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

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

     guix environment OPTIONS PACKAGE...

   By default, this command authenticates the Git checkout in the
current directory; it outputs nothing and exits with exit code zero on
success and non-zero on failure.  COMMIT above denotes the first commit
where authentication takes place, and SIGNER is the OpenPGP fingerprint
of public key used to sign COMMIT.  Together, they form a “channel
introduction” (*note channel introduction: channel-authentication.).  On
your first successful run, the introduction is recorded in the
‘.git/config’ file of your checkout, allowing you to omit them from
subsequent invocations:

     guix git authenticate [OPTIONS...]

   Should you have branches that require different introductions, you
can specify them directly in ‘.git/config’.  For example, if the branch
called ‘personal-fork’ has a different introduction than other branches,
you can extend ‘.git/config’ along these lines:

     [guix "authentication-personal-fork"]
     	introduction-commit = cabba936fd807b096b48283debdcddccfea3900d
     	introduction-signer = C0FF EECA BBA9 E6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
     	keyring = keyring

   The first run also attempts to install pre-push and post-merge hooks,
such that ‘guix git authenticate’ is invoked as soon as you run ‘git
push’, ‘git pull’, and related commands; it does not overwrite
preexisting hooks though.

   The command-line options described below allow you to fine-tune the
process.

‘--extract=DIRECTORY’
‘-x DIRECTORY’
     Открыть репозиторий Git в DIRECTORY вместо текущего каталога.

‘--expression=EXPR’
‘-F FREE’
     Загрузить связку ключей OpenPGP из REFERENCE, ссылки на branch,
     например ‘origin/keyring’ или ‘my-keyring’.  branch должна
     содержать открытые ключи OpenPGP в файлах ‘.key’ либо в двоичной
     форме, либо в “ASCII-armored” виде.  По умолчанию связка ключей
     загружается из branch с именем ‘keyring’.

‘--end=COMMIT’
     Authenticate revisions up to COMMIT.

‘--stats’
     Отобразить статистику подписания commit’ов по завершению.

‘--search=REGEXP’
     Ранее аутентифицированные коммиты кэшируются в файле под
     ‘~/.cache/guix/authentication’.  Эта опция заставляет хранить кеш в
     файле KEY в этом каталоге.

‘--install-from-file=FILE’
     По умолчанию любой коммит, родительский коммит которого не содержит
     файла ‘.guix-authorizations’, считается недостоверным.  Напротив,
     эта опция учитывает авторизацию в FILE для любого коммита, в
     котором отсутствует ‘.guix-authorizations’.  Формат FILE такой же,
     как у ‘.guix-authorizations’ (*note ‘.guix-authorizations’ format:
     channel-authorizations.).


File: guix.ru.info,  Node: Программный интерфейс,  Next: Утилиты,  Prev: Разработка,  Up: Top

8 Программный интерфейс
***********************

GNU Guix предоставляет несколько Scheme программных интерфейсов (API)
для определения, сборки и запроса пакетов.  Первый интерфейс позволяет
пользователям писать высокоуровневые определения пакетов.  Эти
определения относятся к знакомым концепциям упаковки, таким как имя и
версия пакета, его система сборки и зависимости.  Затем эти определения
можно превратить в конкретные действия по сборке.

   Действия по сборке выполняются демоном Guix от имени пользователей.
В стандартной настройке демон имеет доступ на запись в хранилище—каталог
‘/gnu/store’—, в то время как пользователи не имеют.  Рекомендуемая
установка также предусматривает, что демон выполняет сборки в chroot,
под определенными пользователями сборки, чтобы минимизировать влияние на
остальную систему.

   Доступны API нижнего уровня для взаимодействия с демоном и
хранилищем.  Чтобы дать демону команду выполнить действие сборки,
пользователи фактически предоставляют ему “derivation”.  Derivation -
это низкоуровневое представление действий сборки, которые должны быть
предприняты, и среды, в которой они должны происходить - derivation’ы
относятся к определениям пакетов, как сборка для программ на C. Термин
“derivation” происходит от того факта, что результаты сборки
_производные_ от них.

   This chapter describes all these APIs in turn, starting from
high-level package definitions.  *Note Структура исходного кода::, for a
more general overview of the source code.

* Menu:

* Пакетные модули::          Пакеты с точки зрения программиста.
* Описание пакетов::         Описание новых пакетов.
* Defining Package Variants::  Кастомизация пакетов.
* Writing Manifests::        The bill of materials of your environment.
* Системы сборки::           Задание параметров сборки пакетов.
* Фазы сборки::              Фазы процесса сборки пакета.
* Build Utilities::          Импорт описаниий пакетов.
* Search Paths::             Declaring search path environment variables.
* Хранилище::                Работа с хранилищем пакетов.
* Деривации::                Низкоуровневый интерфейс дериваций пакетов.
* Устройство склада::        Чисто функциональный интерфейс доступа к
                               складу.
* G-Expressions::            Управление механизмом сборки.
* Запуск guix repl::         Программирование Guix в Guile
* Using Guix Interactively::  Fine-grain interaction at the REPL.


File: guix.ru.info,  Node: Пакетные модули,  Next: Описание пакетов,  Up: Программный интерфейс

8.1 Пакетные модули
===================

С точки зрения программирования, определения пакетов дистрибутива GNU
предоставляются модулями Guile в пространстве имен ‘(gnu packages ...)’
(1) (*note Guile modules: (guile)Modules.)).  Например, модуль ‘(gnu
packages emacs)’ экспортирует переменную с именем ‘emacs’, которая
привязана к ‘<package>’ объекту (*note Описание пакетов::).

   Пространство имен модуля ‘(gnu packages ...)’ автоматически
сканируется на наличие пакетов с помощью инструментов командной строки.
Например, при запуске ‘guix install emacs’ все модули ‘(gnu packages
...)’ сканируются до тех пор, пока не будет найден тот, который
экспортирует объект пакета с именем ‘emacs’.  Это средство поиска
пакетов реализовано в модуле ‘(gnu packages)’.

   Пользователи могут хранить определения пакетов в модулях с разными
именами - например, ‘(my-packages emacs)’ (2).  Есть два способа сделать
эти определения пакетов видимыми для пользовательских интерфейсов:

  1. Добавить каталог, содержащий модули вашего пакета, в пути поиска с
     помощью флага ‘-L’ команды ‘guix package’ и другие команды (*note
     Стандартные параметры сборки::) или указать переменную окружения
     ‘GUIX_PACKAGE_PATH’, описанную ниже.

  2. Определить “канал” и настроить ‘guix pull’ так, чтобы он учитывал
     его.  Канал - это, по сути, репозиторий Git, содержащий модули
     пакетов.  *Note Каналы::, чтобы узнать больше о том, как определять
     и использовать каналы.

   ‘GUIX_PACKAGE_PATH’ работает аналогично другим переменным пути
поиска:

 -- Environment Variable: GUIX_PACKAGE_PATH
     Это список каталогов, разделенных двоеточиями, для поиска
     дополнительных модулей пакета.  Каталоги, перечисленные в этой
     переменной, имеют приоритет над собственными модулями дистрибутива.

   Дистрибутив полностью “bootstrapped” и “самодостаточный”: каждый
пакет построен исключительно на основе других пакетов в дистрибутиве.
Корнем этого графа зависимостей является небольшой набор “bootstrap
бинарный файлы”, предоставляемых модулем ‘(gnu packages bootstrap)’.
Для получения дополнительной информации о начальной загрузке *note
Начальная загрузка::.

   ---------- Footnotes ----------

   (1) Обратите внимание, что пакеты в ‘(gnu packages ...)’ пространстве
имен модуля не обязательно являются “пакетами GNU”.  Эта схема
именования модулей соответствует обычному соглашению об именах модулей
Guile: ‘gnu’ означает, что эти модули распространяются как часть системы
GNU, а ‘packages’ идентифицирует модули, которые определяют пакеты.

   (2) Обратите внимание, что имя файла и имя модуля должны совпадать.
Например, модуль ‘(my-packages emacs)’ должен храниться в файле
‘my-packages/emacs.scm’ относительно пути загрузки, указанного с помощью
‘--load-path’ или ‘GUIX_PACKAGE_PATH’.  *Note (guile)Modules and the
File System::, для подробностей.


File: guix.ru.info,  Node: Описание пакетов,  Next: Defining Package Variants,  Prev: Пакетные модули,  Up: Программный интерфейс

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
          (list #:configure-flags #~(list "--enable-silent-rules")))
         (inputs (list 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>’ (*note Scheme records: (guile)SRFI-9.).  Этот объект пакета
можно проверить с помощью процедур из модуля ‘(guix packages)’;
например, ‘(package-name hello)’ возвращает—сюрприз!—‘"hello"’.

     Quick start: Impatient?  With luck, you may be able to import part
     or all of the definition of the package you are interested in from
     another repository, using the ‘guix import’ command (*note Запуск
     guix import::).

     Alternatively, try out the Guix-Packager interface
     (https://guix-hpc.gitlabpages.inria.fr/guix-packager/) in your web
     browser to produce a preliminary package definition.

   В приведенном выше примере ‘hello’ определен в собственном модуле
‘(gnu packages hello)’.  Технически в этом нет строгой необходимости, но
это удобно: все пакеты, определенные в модулях под ‘(gnu packages ...)’,
автоматически становятся известны инструментам командной строки (*note
Пакетные модули::).

   В приведенном выше определении пакета стоит отметить несколько
моментов:

   • Поле ‘source’ пакета представляет собой объект ‘<origin>’ (*note
     Интерфейс origin::, for the complete reference).  Здесь
     используется метод ‘url-fetch’ из ‘(guix download)’, что означает,
     что источником является файл, который нужно загрузить через FTP или
     HTTP.

     Префикс ‘mirror://gnu’ указывает ‘url-fetch’ использовать одно из
     зеркал GNU, определенных в ‘(guix download)’.

     Поле ‘sha256’ указывает ожидаемый хэш SHA256 загружаемого файла.
     Это обязательно и позволяет Guix проверять целостность файла.
     Форма ‘(base32 ...)’ указывает представление хеша в формате base32.
     Вы можете получить эту информацию с помощью ‘guix download’ (*note
     Запуск guix download::) ‘guix hash’ (*note Запуск guix hash::).

     При необходимости форма ‘origin’ может также иметь поле ‘patches’
     со списком исправлений, которые необходимо применить, и поле
     ‘snippet’, содержащее Scheme выражение для изменения исходного
     кода.

   • Поле ‘build-system’ указывает процедуру сборки пакета (*note
     Системы сборки::).  Здесь ‘gnu-build-system’ представляет знакомую
     систему сборки GNU, в которой пакеты могут быть настроены, собраны
     и установлены с помощью обычной последовательности команд
     ‘./configure && make && make check && make install’.

     Когда вы начинаете упаковывать нетривиальное программное
     обеспечение, вам могут потребоваться инструменты для управления
     этими этапами сборки, управления файлами и т.д.  *Note Build
     Utilities::, чтобы узнать об этом подробнее.

   • Поле ‘arguments’ определяет параметры для системы сборки (*note
     Системы сборки::).  В примере это интерпретируется
     ‘gnu-build-system’ как запуск запроса ‘configure’ с флагом
     ‘--enable-silent-rules’.

     The value of the ‘arguments’ field is a list of arguments passed to
     the build system and that end up being applied, as with ‘apply’
     (*note ‘apply’: (guile)Fly Evaluation.).

     Последовательность хэш-двоеточие (‘#:’) определяет Scheme “ключевое
     слово” (*note (guile)Keywords::), а ‘#:configure-flags’ - это
     ключевое слово, используемое для передачи аргумента ключевого слова
     системе сборки (*note (guile)Coding With Keywords::).

     What about these hash-tilde (‘#~’) characters?  This is
     Guix-specific syntax introducing a so-called “G-expression” (*note
     G-Expressions::), which denotes code that is “staged” for eventual
     evaluation: this staged code is only evaluated if and when
     attempting to build the package, by the build daemon.  In this
     example, the staged code is the ‘(list ...)’ expression, which
     builds a list of one element, the configure flag.

   • The ‘inputs’ field specifies inputs to the build process—i.e.,
     build-time or run-time dependencies of the package.  Here, we add
     an input, a reference to the ‘gawk’ variable; ‘gawk’ is itself
     bound to a ‘<package>’ object.

     Обратите внимание, что GCC, Coreutils, Bash и другие важные
     инструменты не нужно указывать здесь в качестве inputs.  Вместо
     этого ‘gnu-build-system’ позаботится об их наличии (*note Системы
     сборки::).

     Однако любые другие зависимости необходимо указать в поле ‘inputs’.
     Любая не указанная здесь зависимость будет просто недоступна для
     процесса сборки, что может привести к сбою сборки.

   *Note ссылка на пакет::, для полного описания возможных полей.

     Больше информации: Intimidated by the Scheme language or curious
     about it?  The Cookbook has a short section to get started that
     recaps some of the things shown above and explains the
     fundamentals.  *Note (guix-cookbook)A Scheme Crash Course::, for
     more information.

   После того, как определение пакета введено, пакет может быть
фактически собран с помощью инструмента командной строки ‘guix build’
(*note Запуск guix build::), устраняя любые возникающие ошибки сборки
(*note Отладка ошибок сборки::).  Вы можете легко вернуться к
определению пакета с помощью команды ‘guix edit’ (*note Запуск guix
edit::).  *Note Руководство по упаковке:: для получения дополнительной
информации о том, как тестировать определения пакетов, и *note Запуск
guix lint:: для получения информации о том, как проверить определение на
соответствие стилю.  Наконец, *note Каналы::, чтобы узнать, как
расширить дистрибутив, добавив собственные определения пакетов в
“канал”.

   Наконец, обновление определения пакета до новой исходной версии можно
частично автоматизировать с помощью команды ‘guix refresh’ (*note Запуск
guix refresh::).

   За кулисами derivation, соответствующая объекту ‘<package>’, сначала
вычисляется с помощью процедуры ‘package-diveration’.  Этот вывод
хранится в файле ‘.drv’ в каталоге ‘/gnu/store’.  Действия сборки,
которые он предписывает, затем могут быть реализованы с помощью
процедуры ‘build-derivations’ (*note Хранилище::).

 -- Procedure: package-derivation store package [system]
     Возвращает the ‘<derivation>’ объект PACKAGE для SYSTEM (*note
     Деривации::).

     PACKAGE должен быть допустимым объектом ‘<package>’, а SYSTEM
     должен быть строкой, обозначающей тип системы—например,
     ‘"x86_64-linux"’ для системы GNU на базе x86_64 Linux.  STORE
     должен быть подключен к демону, который работает с хранилищем
     (*note Хранилище::).

Точно так же можно вычислить derivation, которая cross собирает пакет
для некоторой другой системы:

 -- Procedure: package-cross-derivation store package target [system]
     Return the ‘<derivation>’ object of PACKAGE cross-built from SYSTEM
     to TARGET.

     TARGET должен быть допустимым GNU triplet’ом, обозначающим желамое
     оборудование и операционную систему, например ‘"aarch64-linux-gnu"’
     (*note (autoconf)Specifying Target Triplets::).

   Когда у вас есть определения пакетов, вы можете легко определить
_варианты_ этих пакетов.  См.  *Note Defining Package Variants::, чтобы
узнать об этом подробнее.

* Menu:

* ссылка на пакет::          Тип данных package.
* Интерфейс origin::         Тип данных origin.


File: guix.ru.info,  Node: ссылка на пакет,  Next: Интерфейс origin,  Up: Описание пакетов

8.2.1 ‘package’ Ссылка
----------------------

В этом разделе перечислены все параметры, доступные в объявлениях
‘package’ (*note Описание пакетов::).

 -- Тип данных: package
     Это тип данных, представляющий рецепт пакета.

     ‘name’
          Название пакета в виде строки.

     ‘version’
          The version of the package, as a string.  *Note Номера
          версий::, for guidelines.

     ‘source’
          Объект, указывающий, как должен быть получен исходный код
          пакета.  В большинстве случаев это объект ‘origin’, который
          обозначает файл, полученный из Интернета (*note Интерфейс
          origin::).  Это также может быть любой другой объект, подобный
          файлу, например ‘local-file’, который представляет собой файл
          из локальной файловой системы (*note ‘local-file’:
          G-Expressions.).

     ‘система сборки’
          Система сборки, которую следует использовать для сборки пакета
          (*note Системы сборки::).

     ‘arguments’ (default: ‘'()’)
          Аргументы, которые должны быть переданы системе сборки (*note
          Системы сборки::).  Это список, обычно содержащий
          последовательные пары ключевое слово-значение, как в этом
          примере:

               (package
                 (name "example")
                 ;; several fields omitted
                 (arguments
                   (list #:tests? #f                     ;skip tests
                         #:make-flags #~'("VERBOSE=1")   ;pass flags to 'make'
                         #:configure-flags #~'("--enable-frobbing"))))

          The exact set of supported keywords depends on the build
          system (*note Системы сборки::), but you will find that almost
          all of them honor ‘#:configure-flags’, ‘#:make-flags’,
          ‘#:tests?’, and ‘#:phases’.  The ‘#:phases’ keyword in
          particular lets you modify the set of build phases for your
          package (*note Фазы сборки::).

          The REPL has dedicated commands to interactively inspect
          values of some of these arguments, as a convenient debugging
          aid (*note Using Guix Interactively::).

               Compatibility Note: Until version 1.3.0, the ‘arguments’
               field would typically use ‘quote’ (‘'’) or ‘quasiquote’
               (‘`’) and no G-expressions, like so:

                    (package
                      ;; several fields omitted
                      (arguments   ;old-style quoted arguments
                       '(#:tests? #f
                         #:configure-flags '("--enable-frobbing"))))

               To convert from that style to the one shown above, you
               can run ‘guix style -S arguments PACKAGE’ (*note Invoking
               guix style::).

     ‘inputs’ (default: ‘'()’)
     ‘native-inputs’ (default: ‘'()’)
     ‘propagated-inputs’ (default: ‘'()’)
          These fields list dependencies of the package.  Each element
          of these lists is either a package, origin, or other
          “file-like object” (*note G-Expressions::); to specify the
          output of that file-like object that should be used, pass a
          two-element list where the second element is the output (*note
          Пакеты со множественным выходом::, for more on package
          outputs).  For example, the list below specifies three inputs:

               (list libffi libunistring
                     `(,glib "bin"))      ;the "bin" output of GLib

          In the example above, the ‘"out"’ output of ‘libffi’ and
          ‘libunistring’ is used.

               Compatibility Note: Until version 1.3.0, input lists were
               a list of tuples, where each tuple has a label for the
               input (a string) as its first element, a package, origin,
               or derivation as its second element, and optionally the
               name of the output thereof that should be used, which
               defaults to ‘"out"’.  For example, the list below is
               equivalent to the one above, but using the “old input
               style”:

                    ;; Old input style (deprecated).
                    `(("libffi" ,libffi)
                      ("libunistring" ,libunistring)
                      ("glib:bin" ,glib "bin"))  ;the "bin" output of GLib

               This style is now deprecated; it is still supported but
               support will be removed in a future version.  It should
               not be used for new package definitions.  *Note Invoking
               guix style::, on how to migrate to the new style.

          Различие между ‘native-inputs’ и ‘inputs’ необходимо при
          рассмотрении кросс-компиляции.  При кросс-компиляции
          зависимости, перечисленные в ‘input’, создаются для
          архитектуры _target_; и наоборот, зависимости, перечисленные в
          ‘native-inputs’, созданы для архитектуры машины, выполняющей
          _сборку_.

          ‘native-inputs’ обычно используется для перечисления
          инструментов, необходимых во время сборки, но не во время
          выполнения, таких как Autoconf, Automake, pkg-config, Gettext
          или Bison.  ‘guix lint’ может сообщить о вероятных ошибках в
          этой области (*note Запуск guix lint::).

          Наконец, ‘propagated-inputs’ похоже на ‘inputs’, но указанные
          пакеты будут автоматически установлены в профили (*note the
          role of profiles in Guix: Особенности.) вместе с пакетом,
          которому они принадлежат (*note ‘guix package’:
          package-cmd-propagated-inputs, 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")’)
          Список выходных имен пакета.  *Note Пакеты со множественным
          выходом::, для типичного использования дополнительных выходов.

     ‘native-search-paths’ (default: ‘'()’)
     ‘search-paths’ (по умолчанию: ‘'()’)
          A list of ‘search-path-specification’ objects describing
          search-path environment variables honored by the package.
          *Note Search Paths::, for more on search path specifications.

          As for inputs, the distinction between ‘native-search-paths’
          and ‘search-paths’ only matters when cross-compiling.  In a
          cross-compilation context, ‘native-search-paths’ applies
          exclusively to native inputs whereas ‘search-paths’ applies
          only to host inputs.

          Packages such as cross-compilers care about target inputs—for
          instance, our (modified) GCC cross-compiler has
          ‘CROSS_C_INCLUDE_PATH’ in ‘search-paths’, which allows it to
          pick ‘.h’ files for the target system and _not_ those of
          native inputs.  For the majority of packages though, only
          ‘native-search-paths’ makes sense.

     ‘replacement’ (по умолчанию: ‘#f’)
          Это должен быть либо ‘#f’, либо объект пакета, который будет
          использоваться как “замена” для этого пакета.  *Note grafts:
          Обновления безопасности, чтобы узнать подробности.

     ‘synopsis’
          Описание пакета в одну строку.

     ‘description’
          A more elaborate description of the package, as a string in
          Texinfo syntax.

     ‘лицензия’
          Лицензия пакета; значение из ‘(guix licenses)’ или список
          таких значений.

     ‘home-page’
          URL-адрес домашней страницы пакета в виде строки.

     ‘port’ (default: ‘22’)
          Список систем, поддерживаемых пакетом, в виде строк вида
          ‘architecture-kernel’, например ‘"x86_64-linux"’.

     ‘location’ (по умолчанию: исходное местоположение формы ‘package’)
          Исходное расположение пакета.  Это полезно переопределить при
          наследовании от другого пакета, и в этом случае это поле не
          корректируется автоматически.

 -- Macro: 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)
                               (list this-package)
                               '())))

     Ссылка на ‘this-package’ вне определения пакета является ошибкой.

   The following helper procedures are provided to help deal with
package inputs.

 -- Procedure: lookup-package-input package name
 -- Procedure: lookup-package-native-input package name
 -- Procedure: lookup-package-propagated-input package name
 -- Procedure: lookup-package-direct-input package name
     Look up NAME among PACKAGE’s inputs (or native, propagated, or
     direct inputs).  Return it if found, ‘#f’ otherwise.

     NAME is the name of a package or the file name of an origin
     depended on.  Here’s how you might use it:

          (use-modules (guix packages) (gnu packages base))

          (lookup-package-direct-input coreutils "gmp")
          ⇒ #<package gmp@6.2.1 ...>

     In this example we obtain the ‘gmp’ package that is among the
     direct inputs of ‘coreutils’.

     When looking up an origin, use the name that appears in the
     origin’s ‘file-name’ field or its default file name—e.g.,
     ‘"foo-1.2.tar.gz"’.

   Sometimes you will want to obtain the list of inputs needed to
_develop_ a package—all the inputs that are visible when the package is
compiled.  This is what the ‘package-development-inputs’ procedure
returns.

 -- Procedure: package-development-inputs package [system] [#:target #f]
     Return the list of inputs required by PACKAGE for development
     purposes on SYSTEM.  When TARGET is true, return the inputs needed
     to cross-compile PACKAGE from SYSTEM to TARGET, where TARGET is a
     triplet such as ‘"aarch64-linux-gnu"’.

     Note that the result includes both explicit inputs and implicit
     inputs—inputs automatically added by the build system (*note
     Системы сборки::).  Let us take the ‘hello’ package to illustrate
     that:

          (use-modules (gnu packages base) (guix packages))

          hello
          ⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

          (package-direct-inputs hello)
          ⇒ ()

          (package-development-inputs hello)
          ⇒ (("source" ...) ("tar" #<package tar@1.32 ...>) ...)

     In this example, ‘package-direct-inputs’ returns the empty list,
     because ‘hello’ has zero explicit dependencies.  Conversely,
     ‘package-development-inputs’ includes inputs implicitly added by
     ‘gnu-build-system’ that are required to build ‘hello’: tar, gzip,
     GCC, libc, Bash, and more.  To visualize it, ‘guix graph hello’
     would show you explicit inputs, whereas ‘guix graph -t bag hello’
     would include implicit inputs (*note Запуск guix graph::).

   Поскольку пакеты являются обычными 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 вместо значений по
     умолчанию.  *Note Системы сборки::, чтобы узнать больше о системах
     сборки.


File: guix.ru.info,  Node: Интерфейс origin,  Prev: ссылка на пакет,  Up: Описание пакетов

8.2.2 ‘origin’ Справка
----------------------

Этот раздел документирует “origins”.  Объявление ‘origin’ определяет
данные, которые должны быть “произведены”—обычно загружены—и чей хэш
содержимого известен заранее.  Origins в основном используются для
представления исходного кода пакетов (*note Описание пакетов::).  По
этой причине форма ‘origin’ позволяет вам объявлять исправления для
применения к исходному коду, а также фрагменты кода для его изменения.

 -- Тип данных: origin
     Это тип данных, представляющий источник исходного кода.

     ‘uri’
          Объект, содержащий URI источника.  Тип объекта зависит от
          ‘method’ (см.  ниже).  Например, при использовании метода
          URL-FETCH для ‘(guix download)’ допустимые значения ‘uri’:
          URL, представленный в виде строки, или их список.

     ‘method’
          Монадическая процедура, обрабатывающая данный URI. Процедура
          должна принимать по крайней мере три аргумента: значение поля
          ‘uri’, а также алгоритм хеширования и значение хеш-функции,
          указанные в поле ‘hash’.  Она должна возвращать элемент store
          или derivation в store монаде (*note Устройство склада::);
          большинство методов возвращают derivation с фиксированным
          выводом (*note Деривации::).

          Обычно используемые методы включают ‘url-fetch’, который
          извлекает данные из URL-адреса, и ‘git-fetch’, который
          извлекает данные из репозитория Git (см.  ниже).

     ‘sha256’
          Байт-вектор, содержащий хэш SHA-256 источника.  Это эквивалент
          предоставлению объекта SHA256 ‘content-hash’ в поле ‘hash’,
          описанном ниже.

     ‘hash’
          Объект ‘content-hash’ источника—см.  ниже, как использовать
          ‘content-hash’.

          Вы можете получить эту информацию, используя ‘guix download’
          (*note Запуск guix download::) или ‘guix hash’ (*note Запуск
          guix hash::).

     ‘file-name’ (по умолчанию: ‘#f’)
          Имя файла, под которым должен быть сохранен исходный код.
          Когда это ‘#f’, в большинстве случаев будет использоваться
          разумное значение по умолчанию.  В случае, если источник
          извлекается из URL-адреса, будет использоваться имя файла из
          URL-адреса.  Для проверок контроля версий рекомендуется явно
          указывать имя файла, поскольку значение по умолчанию не очень
          информативно.

     ‘patches’ (по умолчанию: ‘'()’)
          Список имен файлов, источников или объектов подобных файлами
          (*note file-like objects: G-Expressions.), указывающих на
          исправления, которые будут применены к источнику.

          Данный список исправлений должен быть безвариативным.  В
          частности, он не может зависеть от значения ‘%current-system’
          или ‘%current-target-system’.

     ‘snippet’ (по умолчанию: ‘#f’)
          G-выражение (*note 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, или может быть байтовым вектором.

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

          (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’,
описанный ниже.

 -- Procedure: url-fetch url hash-algo hash [name] [#:executable? #f]
     Return a fixed-output derivation that fetches data from URL (a
     string, or a list of strings denoting alternate URLs), which is
     expected to have hash HASH of type HASH-ALGO (a symbol).  By
     default, the file name is the base name of URL; optionally, NAME
     can specify a different file name.  When EXECUTABLE? is true, make
     the downloaded file executable.

     Когда один из URL-адресов начинается с ‘mirror://’, тогда его
     хост-часть интерпретируется как имя схемы зеркала, взятой из
     ‘%mirror-file’.

     В качестве альтернативного варианта, если URL-адрес начинается с
     ‘file://’, вернуть соответствующее имя файла в store.

   Аналогичным образом, модуль ‘(guix git-download)’ определяет метод
источника ‘git-download’, который извлекает данные из репозитория
управления версиями Git, и тип данных ‘git-reference’ для описания
репозиторий и ревизия для загрузки.

 -- Procedure: git-fetch ref hash-algo hash [name]
     Вернуть derivation с фиксированным выводом, которая выбирает объект
     REF, ‘<git-reference>’.  Ожидается, что на выходе будет рекурсивный
     хеш HASH типа HASH-ALGO (символ).  Использовать NAME в качестве
     имени файла или общее имя, если ‘#f’.

 -- Procedure: git-fetch/lfs ref hash-algo hash [name]
     This is a variant of the ‘git-fetch’ procedure that supports the
     Git LFS (Large File Storage) extension.  This may be useful to pull
     some binary test data to run the test suite of a package, for
     example.

 -- Тип данных: build-machine
     Управление конфигурацией операционной системы.

     ‘url’
          URL-адрес репозитория Git для клонирования.

     ‘commit’
          This string denotes either the commit to fetch (a hexadecimal
          string), or the tag to fetch.  You can also use a “short”
          commit ID or a ‘git describe’ style identifier such as
          ‘v1.0.1-10-g58d7909c97’.

     ‘features’ (default: ‘'()’)
          Это логическое значение (boolean) указывает, нужно ли
          рекурсивно получать подмодули Git.

     Пример ниже обозначает тег ‘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"))

   Для репозиториев Mercurial, модуль ‘(guix hg-download)’ определяет
метод ‘hg-fetch’ и тип данных ‘hg-reference’ для поддержки системы
контроля версий Mercurial.

 -- 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 ‘#f’.

 -- Data Type: hg-reference
     This data type represents a Mercurial reference for ‘hg-fetch’ to
     retrieve.

     ‘url’
          The URL of the Mercurial repository to clone.

     ‘changeset’
          This string denotes the changeset to fetch.

   For Subversion repositories, the module ‘(guix svn-download)’ defines
the ‘svn-fetch’ origin method and ‘svn-reference’ data type for support
of the Subversion version control system.

 -- Procedure: svn-fetch ref hash-algo hash [name]
     Вернуть derivation с фиксированным выводом, которая выбирает объект
     REF, ‘<svn-reference>’.  Ожидается, что на выходе будет рекурсивный
     хеш HASH типа HASH-ALGO (символ).  Использовать NAME в качестве
     имени файла или общее имя, если ‘#f’.

 -- Data Type: svn-reference
     This data type represents a Subversion reference for ‘svn-fetch’ to
     retrieve.

     ‘url’
          The URL of the Subversion repository to clone.

     ‘revision’
          This string denotes the revision to fetch specified as a
          number.

     ‘features’ (default: ‘'()’)
          This Boolean indicates whether to recursively fetch Subversion
          “externals”.

     ‘user-name’ (default: ‘#f’)
          The name of an account that has read-access to the repository,
          if the repository isn’t public.

     ‘password’ (default: ‘#f’)
          Password to access the Subversion repository, if required.

   For Bazaar repositories, the module ‘(guix bzr-download)’ defines the
‘bzr-fetch’ origin method and ‘bzr-reference’ data type for support of
the Bazaar version control system.

 -- Procedure: bzr-fetch ref hash-algo hash [name]
     Вернуть derivation с фиксированным выводом, которая выбирает объект
     REF, ‘<bzr-reference>’.  Ожидается, что на выходе будет рекурсивный
     хеш HASH типа HASH-ALGO (символ).  Использовать NAME в качестве
     имени файла или общее имя, если ‘#f’.

 -- Data Type: bzr-reference
     This data type represents a Bazaar reference for ‘bzr-fetch’ to
     retrieve.

     ‘url’
          The URL of the Bazaar repository to clone.

     ‘revision’
          This string denotes revision to fetch specified as a number.

   For CVS repositories, the module ‘(guix cvs-download)’ defines the
‘cvs-fetch’ origin method and ‘cvs-reference’ data type for support of
the Concurrent Versions System (CVS).

 -- Procedure: cvs-fetch ref hash-algo hash [name]
     Вернуть derivation с фиксированным выводом, которая выбирает объект
     REF, ‘<cvs-reference>’.  Ожидается, что на выходе будет рекурсивный
     хеш HASH типа HASH-ALGO (символ).  Использовать NAME в качестве
     имени файла или общее имя, если ‘#f’.

 -- Data Type: cvs-reference
     This data type represents a CVS reference for ‘cvs-fetch’ to
     retrieve.

     ‘root-directory’
          The CVS root directory.

     ‘module’
          Module to fetch.

     ‘revision’
          Revision to fetch.

     The example below denotes a version of gnu-standards to fetch:

          (cvs-reference
            (root-directory ":pserver:anonymous@cvs.savannah.gnu.org:/sources/gnustandards")
            (module "gnustandards")
            (revision "2020-11-25"))


File: guix.ru.info,  Node: Defining Package Variants,  Next: Writing Manifests,  Prev: Описание пакетов,  Up: Программный интерфейс

8.3 Defining Package Variants
=============================

Одна из приятных вещей в Guix заключается в том, что, учитывая
определение пакета, вы можете легко _наследовать_ варианты этого
пакета—для другой версии, с разными зависимостями, разными параметрами
компиляции и так далее.  Некоторые из этих пользовательских пакетов
можно определить прямо из командной строки (*note Параметры
преобразования пакета::).  В этом разделе описывается, как определять
варианты пакета в коде.  Это также может быть полезно в “манифестах”
(*note Writing Manifests::) и в вашей собственной коллекции пакетов
(*note Создание канала::)!

   Как обсуждалось ранее, пакеты—это объекты первого класса на языке
Scheme.  Модуль ‘(guix packages)’ предоставляет конструкцию ‘package’
для определения новых объектов пакета (*note ссылка на пакет::).  Самый
простой способ определить вариант пакета—использовать ключевое слово
‘inherit’ вместе с ‘package’.  Это позволяет вам наследовать от
определения пакета, переопределяя нужные поля.

   Например, учитывая переменную ‘hello’, которая содержит определение
для текущей версии GNU Hello, вот как вы могли бы определить вариант для
версии 2.2 (выпущенной в 2006 году, это винтаж!):

     (use-modules (gnu packages guile))  ;for 'guile-json'

     (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-version’ or
‘--with-source’ package transformations option do.  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.

   Вы также можете определить варианты с другим набором зависимостей,
чем исходный пакет.  Например, пакет ‘gdb’ по умолчанию зависит от
‘guile’, но поскольку это необязательная зависимость, вы можете
определить вариант, который удаляет эту зависимость следующим образом:

     (use-modules (gnu packages gdb))   ;for 'gdb'

     (define gdb-sans-guile
       (package
         (inherit gdb)
         (inputs (modify-inputs (package-inputs gdb)
                   (delete "guile")))))

   The ‘modify-inputs’ form above removes the ‘"guile"’ package from the
‘inputs’ field of ‘gdb’.  The ‘modify-inputs’ macro is a helper that can
prove useful anytime you want to remove, add, or replace package inputs.

 -- Macro: modify-inputs inputs clauses
     Modify the given package inputs, as returned by ‘package-inputs’ &
     co., according to the given clauses.  Each clause must have one of
     the following forms:

     ‘(delete NAME...)’
          Delete from the inputs packages with the given NAMEs
          (strings).

     ‘(prepend PACKAGE...)’
          Add PACKAGEs to the front of the input list.

     ‘(append PACKAGE...)’
          Add PACKAGEs to the end of the input list.

     ‘(replace NAME REPLACEMENT)’
          Replace the package called NAME with REPLACEMENT.

     The example below removes the GMP and ACL inputs of Coreutils and
     adds libcap to the front of the input list:

          (modify-inputs (package-inputs coreutils)
            (delete "gmp" "acl")
            (prepend libcap))

     The example below replaces the ‘guile’ package from the inputs of
     ‘guile-redis’ with ‘guile-2.2’:

          (modify-inputs (package-inputs guile-redis)
            (replace "guile" guile-2.2))

     The last type of clause is ‘append’, to add inputs at the back of
     the list.

   В некоторых случаях вам может быть полезно написать функции
(“процедуры” Scheme), которые возвращают пакет на основе некоторых
параметров.  Например, рассмотрим библиотеку ‘luasocket’ для языка
программирования Lua.  Мы хотим создать пакеты ‘luasocket’ для основных
версий Lua.  Один из способов сделать это—определить процедуру, которая
принимает пакет Lua и возвращает зависящий от него пакет ‘luasocket’:

     (define (make-lua-socket name lua)
       ;; Return a luasocket package built with LUA.
       (package
         (name name)
         (version "3.0")
         ;; several fields omitted
         (inputs (list 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))

   Здесь мы определили пакеты ‘lua5.1-socket’ и ‘lua5.2-socket’, вызвав
‘make-lua-socket’ с разными аргументами.  См.  *Note
(guile)Procedures::, для получения дополнительной информации о
процедурах.  Наличие общедоступных определений верхнего уровня для этих
двух пакетов означает, что на них можно ссылаться из командной строки
(*note Пакетные модули::).

   Это довольно простые варианты пакета.  Для удобства модуль ‘(guix
transformations)’ предоставляет высокоуровневый интерфейс, который
напрямую сопоставляется с более сложными параметрами преобразования
пакетов (*note Параметры преобразования пакета::):

 -- Procedure: options->transformation opts
     Возвращает процедуру, которая при передаче объекта для сборки
     (пакета, производной и т.  д.), применяет преобразования, указанные
     в OPTS, и возвращает результирующие объекты.  OPTS должен быть
     списком пар символ/строка, например:

          ((with-branch . "guile-gcrypt=master")
          (without-tests . "libgcrypt"))

     Каждый символ именует преобразование, а соответствующая строка
     (string) является аргументом этого преобразования.

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

     guix build guix \
       --with-branch=guile-gcrypt=master \
       --with-debug-info=zlib

Вывод должен быть таким:

     (use-package-modules guile emacs)

     (define transform
       ;; The package transformation procedure.
       (options->transformation
        '((with-branch . "guile-gcrypt=master")
          (with-debug-info . "zlib"))))

     (packages->manifest
     (list (transform (specification->package "guix"))))

   Процедура ‘options-> transformation’ удобна, но, возможно, не так
гибка, как вам хотелось бы.  Как это реализовано?  Проницательный
читатель, вероятно, заметил, что большинство вариантов преобразования
пакетов выходят за рамки поверхностных изменений, показанных в первых
примерах этого раздела: они включают “перезапись входных данных”, в
результате чего граф зависимостей пакета переписывается путем замены
определенных входных данных другими.

   Перезапись графа зависимостей для замены пакетов в графе реализуется
процедурой ‘package-input-rewriting’ в ‘(guix packages)’.

 -- Процедура Scheme: package-input-rewriting replacements
          [rewrite-name] [#:deep? #t] [#:recursive? #f] Возвращает
          процедуру, которая при передаче
     пакета заменяет его прямые и косвенные зависимости, включая неявные
     входы, когда DEEP? истинна, согласно REPLACEMENTS.  REPLACEMENTS -
     это список пар пакетов; первый элемент каждой пары - это заменяемый
     пакет, а второй - заменяющий.

     When RECURSIVE? is true, apply replacements to the right-hand sides
     of REPLACEMENTS as well, recursively.

     При необходимости, 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’ (*note
‘--with-input’: Параметры преобразования пакета.).

   Следующий вариант ‘package-input-rewriting’ может сопоставлять
пакеты, подлежащие замене, по имени, а не по идентификатору.

 -- Procedure: package-input-rewriting/spec REPLACEMENTS [#:deep? #t]
          [#:replace-hidden? #t] Return a procedure that, given a
     package, applies the given REPLACEMENTS to all the package graph,
     including implicit inputs unless DEEP? is false.

     REPLACEMENTS is a list of spec/procedures pair; each spec is a
     package specification such as ‘"gcc"’ or ‘"guile@2"’, and each
     procedure takes a matching package and returns a replacement for
     that package.  Matching packages that have the ‘hidden?’ property
     set are not replaced unless REPLACE-HIDDEN? is set to true.

   Приведенный выше пример можно переписать так:

     (define libressl-instead-of-openssl
       ;; Replace all the packages called "openssl" with LibreSSL.
       (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

   Ключевое отличие здесь в том, что на этот раз пакеты сопоставляются
по спецификации, а не по идентичности.  Другими словами, любой пакет в
графе, который называется ‘openssl’, будет заменен.

   Более общая процедура для перезаписи графа зависимостей пакетов - это
‘package-mapping’: она поддерживает произвольные изменения узлов в
графе.

 -- Procedure: package-mapping proc [cut?] [#:deep? #f]
     Вернуть процедуру, которая для данного пакета применяет PROC ко
     всем зависимым пакетам и возвращает полученный пакет.  Процедура
     останавливает рекурсию, когда CUT? возвращает истину для данного
     пакета.  Когда DEEP? истинно, PROC также применяется к неявным
     входным данным.

     Tips: Understanding what a variant really looks like can be
     difficult as one starts combining the tools shown above.  There are
     several ways to inspect a package before attempting to build it
     that can prove handy:

        • You can inspect the package interactively at the REPL, for
          instance to view its inputs, the code of its build phases, or
          its configure flags (*note Using Guix Interactively::).

        • When rewriting dependencies, ‘guix graph’ can often help
          visualize the changes that are made (*note Запуск guix
          graph::).


File: guix.ru.info,  Node: Writing Manifests,  Next: Системы сборки,  Prev: Defining Package Variants,  Up: Программный интерфейс

8.4 Writing Manifests
=====================

‘guix’ commands let you specify package lists on the command line.  This
is convenient, but as the command line becomes longer and less trivial,
it quickly becomes more convenient to have that package list in what we
call a “manifest”.  A manifest is some sort of a “bill of materials”
that defines a package set.  You would typically come up with a code
snippet that builds the manifest, store it in a file, say
‘manifest.scm’, and then pass that file to the ‘-m’ (or ‘--manifest’)
option that many ‘guix’ commands support.  For example, here’s what a
manifest for a simple package set might look like:

     ;; Manifest for three packages.
     (specifications->manifest '("gcc-toolchain" "make" "git"))

   Once you have that manifest, you can pass it, for example, to ‘guix
package’ to install just those three packages to your profile (*note
‘-m’ option of ‘guix package’: profile-manifest.):

     guix package -m manifest.scm

...  or you can pass it to ‘guix shell’ (*note ‘-m’ option of ‘guix
shell’: shell-manifest.) to spawn an ephemeral environment:

     guix shell -m manifest.scm

...  or you can pass it to ‘guix pack’ in pretty much the same way
(*note ‘-m’ option of ‘guix pack’: pack-manifest.).  You can store the
manifest under version control, share it with others so they can easily
get set up, etc.

   But how do you write your first manifest?  To get started, maybe
you’ll want to write a manifest that mirrors what you already have in a
profile.  Rather than start from a blank page, ‘guix package’ can
generate a manifest for you (*note ‘guix package --export-manifest’:
export-manifest.):

     # Write to 'manifest.scm' a manifest corresponding to the
     # default profile, ~/.guix-profile.
     guix package --export-manifest > manifest.scm

   Or maybe you’ll want to “translate” command-line arguments into a
manifest.  In that case, ‘guix shell’ can help (*note ‘guix shell
--export-manifest’: shell-export-manifest.):

     # Write a manifest for the packages specified on the command line.
     guix shell --export-manifest gcc-toolchain make git > manifest.scm

   In both cases, the ‘--export-manifest’ option tries hard to generate
a faithful manifest; in particular, it takes package transformation
options into account (*note Параметры преобразования пакета::).

     Примечание: Manifests are _symbolic_: they refer to packages of the
     channels _currently in use_ (*note Каналы::).  In the example
     above, ‘gcc-toolchain’ might refer to version 14 today, but it
     might refer to version 16 two years from now.

     If you want to “pin” your software environment to specific package
     versions and variants, you need an additional piece of information:
     the list of channel revisions in use, as returned by ‘guix
     describe’.  *Note Копирование Guix::, for more information.

   Once you’ve obtained your first manifest, perhaps you’ll want to
customize it.  Since your manifest is code, you now have access to all
the Guix programming interfaces!

   Let’s assume you want a manifest to deploy a custom variant of GDB,
the GNU Debugger, that does not depend on Guile, together with another
package.  Building on the example seen in the previous section (*note
Defining Package Variants::), you can write a manifest along these
lines:

     (use-modules (guix packages)
                  (gnu packages gdb)               ;для 'gdb'
                  (gnu packages version-control))  ;для 'git'

     ;; Определить вариант GDB без зависимости от Guile.
     (define gdb-sans-guile
       (package
         (inherit gdb)
         (inputs (modify-inputs (package-inputs gdb)
                   (delete "guile")))))

     ;; Return a manifest containing that one package plus Git.
     (packages->manifest (list gdb-sans-guile git))

   Note that in this example, the manifest directly refers to the ‘gdb’
and ‘git’ variables, which are bound to a ‘package’ object (*note ссылка
на пакет::), instead of calling ‘specifications->manifest’ to look up
packages by name as we did before.  The ‘use-modules’ form at the top
lets us access the core package interface (*note Описание пакетов::) and
the modules that define ‘gdb’ and ‘git’ (*note Пакетные модули::).
Seamlessly, we’re weaving all this together—the possibilities are
endless, unleash your creativity!

   The data type for manifests as well as supporting procedures are
defined in the ‘(guix profiles)’ module, which is automatically
available to code passed to ‘-m’.  The reference follows.

 -- Data Type: manifest
     Data type representing a manifest.

     It currently has one field:

     ‘entries’
          This must be a list of ‘manifest-entry’ records—see below.

 -- Data Type: manifest-entry
     Data type representing a manifest entry.  A manifest entry contains
     essential metadata: a name and version string, the object (usually
     a package) for that entry, the desired output (*note Пакеты со
     множественным выходом::), and a number of optional pieces of
     information detailed below.

     Most of the time, you won’t build a manifest entry directly;
     instead, you will pass a package to ‘package->manifest-entry’,
     described below.  In some unusual cases though, you might want to
     create manifest entries for things that are _not_ packages, as in
     this example:

          ;; Manually build a single manifest entry for a non-package object.
          (let ((hello (program-file "hello" #~(display "Hi!"))))
            (manifest-entry
              (name "foo")
              (version "42")
              (item
               (computed-file "hello-directory"
                               #~(let ((bin (string-append #$output "/bin")))
                                   (mkdir #$output) (mkdir bin)
                                    (symlink #$hello
                                             (string-append bin "/hello")))))))

     Доступны следующие поля:

     ‘name’
     ‘version’
          Name and version string for this entry.

     ‘item’
          A package or other file-like object (*note file-like objects:
          G-Expressions.).

     ‘output’ (default: ‘"out"’)
          Output of ‘item’ to use, in case ‘item’ has multiple outputs
          (*note Пакеты со множественным выходом::).

     ‘dependencies’ (default: ‘'()’)
          List of manifest entries this entry depends on.  When building
          a profile, dependencies are added to the profile.

          Typically, the propagated inputs of a package (*note
          ‘propagated-inputs’: ссылка на пакет.) end up having a
          corresponding manifest entry in among the dependencies of the
          package’s own manifest entry.

     ‘search-paths’ (по умолчанию: ‘'()’)
          The list of search path specifications honored by this entry
          (*note Search Paths::).

     ‘properties’ (default: ‘'()’)
          List of symbol/value pairs.  When building a profile, those
          properties get serialized.

          This can be used to piggyback additional metadata—e.g., the
          transformations applied to a package (*note Параметры
          преобразования пакета::).

     ‘parent’ (default: ‘(delay #f)’)
          A promise pointing to the “parent” manifest entry.

          This is used as a hint to provide context when reporting an
          error related to a manifest entry coming from a ‘dependencies’
          field.

 -- Procedure: concatenate-manifests lst
     Concatenate the manifests listed in LST and return the resulting
     manifest.

 -- Procedure: package->manifest-entry package [output] [#:properties]
     Return a manifest entry for the OUTPUT of package PACKAGE, where
     OUTPUT defaults to ‘"out"’, and with the given PROPERTIES.  By
     default PROPERTIES is the empty list or, if one or more package
     transformations were applied to PACKAGE, it is an association list
     representing those transformations, suitable as an argument to
     ‘options->transformation’ (*note ‘options->transformation’:
     Defining Package Variants.).

     The code snippet below builds a manifest with an entry for the
     default output and the ‘send-email’ output of the ‘git’ package:

          (use-modules (gnu packages version-control))

          (manifest (list (package->manifest-entry git)
                          (package->manifest-entry git "send-email")))

 -- Procedure: packages->manifest packages
     Return a list of manifest entries, one for each item listed in
     PACKAGES.  Elements of PACKAGES can be either package objects or
     package/string tuples denoting a specific output of a package.

     Using this procedure, the manifest above may be rewritten more
     concisely:

          (use-modules (gnu packages version-control))

          (packages->manifest (list git `(,git "send-email")))

 -- Procedure: package->development-manifest package [system] [#:target]
     Return a manifest for the “development inputs” of PACKAGE for
     SYSTEM, optionally when cross-compiling to TARGET.  Development
     inputs include both explicit and implicit inputs of PACKAGE.

     Like the ‘-D’ option of ‘guix shell’ (*note ‘guix shell -D’:
     shell-development-option.), the resulting manifest describes the
     environment in which one can develop PACKAGE.  For example, suppose
     you’re willing to set up a development environment for Inkscape,
     with the addition of Git for version control; you can describe that
     “bill of materials” with the following manifest:

          (use-modules (gnu packages inkscape)          ;for 'inkscape'
                       (gnu packages version-control))  ;for 'git'

          (concatenate-manifests
           (list (package->development-manifest inkscape)
                 (packages->manifest (list git))))

     In this example, the development manifest that
     ‘package->development-manifest’ returns includes the compiler
     (GCC), the many supporting libraries (Boost, GLib, GTK, etc.), and
     a couple of additional development tools—these are the dependencies
     ‘guix show inkscape’ lists.

   Last, the ‘(gnu packages)’ module provides higher-level facilities to
build manifests.  In particular, it lets you look up packages by
name—see below.

 -- Procedure: specifications->manifest specs
     Given SPECS, a list of specifications such as ‘"emacs@25.2"’ or
     ‘"guile:debug"’, return a manifest.  Specs have the format that
     command-line tools such as ‘guix install’ and ‘guix package’
     understand (*note Вызов guix package::).

     As an example, it lets you rewrite the Git manifest that we saw
     earlier like this:

          (specifications->manifest '("git" "git:send-email"))

     Notice that we do not need to worry about ‘use-modules’, importing
     the right set of modules, and referring to the right variables.
     Instead, we directly refer to packages in the same way as on the
     command line, which can often be more convenient.


File: guix.ru.info,  Node: Системы сборки,  Next: Фазы сборки,  Prev: Writing Manifests,  Up: Программный интерфейс

8.5 Системы сборки
==================

В каждом определении пакета указывается “система сборки” и аргументы для
этой системы сборки (*note Описание пакетов::).  Это поле ‘build-system’
представляет процедуру сборки пакета, а также неявные зависимости этой
процедуры сборки.

   Системы сборки - это объекты ‘<build-system>’.  Интерфейс для их
создания и управления ими предоставляется модулем ‘(guix build-system)’,
а фактические системы сборки экспортируются определенными модулями.

   Под капотом системы сборки сначала компилируют объекты пакета в
“bag”.  “bag” похож на пакет, но с меньшим количеством украшений—другими
словами, bag - это представление пакета нижнего уровня, которое включает
в себя все входные данные этого пакета, включая те, которые были неявно
добавлены система сборки.  Это промежуточное представление затем
компилируется в derivation (*note Деривации::).
‘package-with-c-toolchain’ - это пример способа изменить неявные входные
данные, которые использует система сборки пакета (*note
‘package-with-c-toolchain’: ссылка на пакет.).

   Системы сборки принимают необязательный список из “arguments”.  В
определениях пакетов они передаются через поле ‘arguments’ (*note
Описание пакетов::).  Обычно это аргументы ключевого слова (*note
keyword arguments in Guile: (guile)Optional Arguments.).  Значение этих
аргументов обычно оценивается в “build stratum”—то есть процессом Guile,
запущенным демоном (*note Деривации::).

   Основная система сборки - это ‘gnu-build-system’, которая реализует
стандартную процедуру сборки для GNU и многих других пакетов.  Она
предоставляется модулем ‘(guix build-system gnu)’.

 -- Variable: gnu-build-system
     ‘gnu-build-system’ представляет систему сборки GNU и ее варианты
     (*note configuration and makefile conventions:
     (standards)Configuration.).

     Вкратце, пакеты, использующие его, настраиваются, собираются и
     устанавливаются с помощью обычной последовательности команд ‘./
     configure && make && make check && make install’.  На практике
     часто требуется несколько дополнительных шагов.  Все эти шаги
     разбиты на отдельные “фазы”.  *Note Фазы сборки::, чтобы узнать
     больше о фазах сборки и способах их настройки.

     Кроме того, эта система сборки гарантирует, что доступна
     “стандартная” среда для пакетов GNU. Сюда входят такие инструменты,
     как GCC, libc, Coreutils, Bash, Make, Diffutils, grep и sed (полный
     список см.  в модуле ‘(guix build-system gnu)’).  Мы называем их
     “неявными входами” пакета, потому что в определениях пакетов они не
     упоминаются.

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

     ‘build phases’
          Считать список каналов из файла FILE вместо
          ‘~/.config/guix/channels.scm’.  FILE должен содержать код
          Scheme, который определяет список объектов "канал".  См.
          *Note Каналы:: для подробной информации.

     ‘Конфигурирование системы’
          Это список флагов (строк), переданных в сценарий (script)
          ‘configure’.  См.  *Note Описание пакетов::.

     ‘#:make-flags’
          Этот список строк содержит флаги, передаваемые в качестве
          аргументов для вызовов ‘make’ на этапах ‘build’, ‘check’ и
          ‘install’.

     ‘#:out-of-source?’
          Это логическое значение, ‘#f’ по умолчанию, указывает, следует
          ли запускать сборки в каталоге сборки отдельно от исходников.

          Когда это значение истинно, на этапе ‘configure’ создается
          отдельный каталог сборки, происходит переход в этот каталог и
          оттуда запускается сценарий ‘configure’.  Это полезно для
          пакетов, которым это необходимо, таких как ‘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 (*note ‘--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.  *Note the ‘validate-runpath’ phase:
          phase-validate-runpath, for details.

     ‘#: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 (*note Подстановки::).

     ‘--references’
     ‘--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 (*note Запуск guix size::).

     Most other build systems support these keyword arguments.

   Другие объекты ‘<build-system>’ определены для поддержки других
соглашений и инструментов, используемых пакетами свободного программного
обеспечения.  Они наследуют большую часть ‘gnu-build-system’ и
различаются в основном набором входных данных, неявно добавляемых в
процесс сборки, и списком выполняемых фаз.  Некоторые из этих систем
сборки перечислены ниже.

 -- Variable: agda-build-system
     This variable is exported by ‘(guix build-system agda)’.  It
     implements a build procedure for Agda libraries.

     It adds ‘agda’ to the set of inputs.  A different Agda can be
     specified with the ‘#:agda’ key.

     The ‘#:plan’ key is a list of cons cells ‘(REGEXP . PARAMETERS)’,
     where REGEXP is a regexp that should match the ‘.agda’ files to
     build, and PARAMETERS is an optional list of parameters that will
     be passed to ‘agda’ when type-checking it.

     When the library uses Haskell to generate a file containing all
     imports, the convenience ‘#:gnu-and-haskell?’ can be set to ‘#t’ to
     add ‘ghc’ and the standard inputs of ‘gnu-build-system’ to the
     input list.  You will still need to manually add a phase or tweak
     the ‘'build’ phase, as in the definition of ‘agda-stdlib’.

 -- Variable: ant-build-system
     Эта переменная экспортируется ‘(guix build-system ant)’.  Она
     реализует процедуру сборки пакетов Java, которые можно собрать с
     помощью Ant build tool (https://ant.apache.org/).

     Она добавляет к набору входных данных как ‘ant’, так и “Java
     Development Kit” (JDK), предоставленные пакетом ‘icedtea’.
     Различные пакеты можно указать с помощью параметров ‘#:ant’ и
     ‘#:jdk’ соответственно.

     Когда исходный пакет не предоставляет подходящий файл сборки Ant,
     параметр ‘#:jar-name’ можно использовать для создания минимального
     файла сборки Ant ‘build.xml’ с задачами для создания указанного
     архива jar.  В этом случае параметр ‘#:source-dir’ можно
     использовать для указания подкаталога источника, по умолчанию -
     src.

     Параметр ‘#:main-class’ можно использовать с минимальным файлом
     сборки ant для указания основного класса результирующего jar-файла.
     Это делает файл jar исполняемым.  Параметр ‘#:test-include’ можно
     использовать для указания списка запускаемых тестов junit.  По
     умолчанию это ‘(list "**/*Test.java")’.  ‘#:test-exclude’ можно
     использовать для отключения некоторых тестов.  По умолчанию это
     ‘(list "**/Abstract*.java")’, потому что абстрактные классы не
     могут быть запущены как тесты.

     Параметр ‘#:build-target’ можно использовать для указания задачи
     Ant, которая должна выполняться на этапе ‘build’.  По умолчанию
     будет запущена задача jar.

 -- Variable: android-ndk-build-system
     Эта переменная экспортируется ‘(guix build-system android-ndk)’.
     Она реализует процедуру сборки пакетов Android NDK (собственный
     комплект разработки) с использованием процесса сборки, специфичного
     для Guix.

     Система сборки предполагает, что пакеты устанавливают свои файлы
     общедоступного интерфейса (заголовки) в подкаталог ‘include’ вывода
     ‘out’, а их библиотеки - в подкаталог ‘lib’ вывода ‘out’.

     Также предполагается, что объединение всех зависимостей пакета не
     имеет конфликтующих файлов.

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

 -- Variable: asdf-build-system/source
 -- Variable: asdf-build-system/sbcl
 -- Variable: asdf-build-system/ecl
 -- Variable: asdf-build-system/clasp

     Эти переменные, экспортированные ‘(guix build-system asdf)’,
     реализуют процедуры сборки для пакетов Common Lisp с использованием
     “ASDF” (https://common-lisp.net/project/asdf/).  ASDF - это
     средство определения системы для программ и библиотек Common Lisp.

     Система ‘asdf-build-system/source’ устанавливает пакеты в исходной
     форме и может быть загружена с использованием любой
     распространенной реализации Lisp через ASDF. Другие, такие как
     ‘asdf-build-system/sbcl’, устанавливают двоичные системы в формате,
     понятном конкретной реализации.  Эти системы сборки также могут
     использоваться для создания исполняемых программ или образов lisp,
     которые содержат набор предварительно загруженных пакетов.

     В системе сборки используются соглашения об именах.  Для бинарных
     пакетов перед именем пакета должен стоять префикс реализации lisp,
     например ‘sbcl-’ для ‘asdf-build-system/sbcl’.

     Кроме того, соответствующий исходный пакет должен быть помечен с
     использованием того же соглашения, что и пакеты Python (*note
     Модули Python::), с использованием префикса ‘cl-’.

     Для создания исполняемых программ и образов можно использовать
     процедуры сборки ‘build-program’ и ‘build-image’.  Их следует
     вызывать в фазе сборки после фазы ‘create-symlinks’, чтобы только
     что созданную систему можно было использовать в полученном образе.
     ‘build-program’ требует, чтобы список выражений Common Lisp был
     передан в качестве аргумента ‘#:entry-program’.

     Если система не определена в собственном файле ‘.asd’ с тем же
     именем, тогда следует использовать параметр ‘#:asd-file’, чтобы
     указать, в каком файле определена система.  Кроме того, если пакет
     определяет систему для своих тестов в отдельном файле, он будет
     загружен перед запуском тестов, если он указан параметром
     ‘#:test-asd-file’.  Если он не установлен, будут попробованы файлы
     ‘<system>-tests.asd’, ‘<system>-test.asd’, ‘tests.asd’ и
     ‘test.asd’, если они есть.

     Если по какой-то причине пакет должен быть назван иначе, чем это
     предлагается в соглашениях об именах, можно использовать параметр
     ‘#:asd-system-name’ для указания имени системы.

 -- Variable: cargo-build-system
     Эта переменная экспортируется ‘(guix build-system cargo)’.  Она
     поддерживает сборку пакетов с использованием Cargo, инструмента
     сборки языка программирования Rust (https://www.rust-lang.org).

          Deprecation warning: Parameters ‘#:cargo-inputs’ and
          ‘#:cargo-development-inputs’, previously used for specifying
          source inputs, are deprecated.  Their support will be removed
          after Dec.  31, 2026.

     It adds ‘rust’ and ‘rust:cargo’ to the set of inputs.  A different
     Rust package can be specified with the ‘#:rust’ parameter.

     In its ‘unpack-rust-crates’, ‘configure’ and
     ‘patch-cargo-checksums’ phases, this build system will make any
     source inputs 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.

     This build system supports Cargo workspaces
     (https://doc.rust-lang.org/cargo/reference/workspaces.html).
     Parameter ‘#:cargo-package-crates’ (default: ‘''()’) allows
     specifying names of library crates to package in the ‘package’
     phase.  Specified crates are packaged from left to right, in case
     there’s dependency among them.  For example, specifying
     ‘''("pcre2-sys" "pcre2")’ will package ‘"pcre2-sys"’ first and then
     ‘"pcre2"’.  Parameter ‘#:cargo-install-paths’ (default: ‘''()’)
     allows specifying paths of binary crates to install in the
     ‘install’ phase, ‘''("crates/atuin")’, for example.

     *Note Rust Crates пакеты::, for packaging guidelines.

 -- Variable: chicken-build-system
     This variable is exported by ‘(guix build-system chicken)’.  It
     builds CHICKEN Scheme (https://call-cc.org/) 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.

     Например, если вы создаете пакет, содержащий Bash, с помощью:

          (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.

 -- Variable: copy-build-system
     Эта переменная экспортируется в ‘(guix build-system copy)’.  Она
     поддерживает сборку простых пакетов, которые не требуют большой
     компиляции, в основном просто перемещения файлов.

     Она добавляет большую часть пакетов ‘gnu-build-system’ в набор
     входных данных.  По этой причине ‘copy-build-system’ не требуется
     весь шаблонный код, часто необходимый для ‘trivial-build-system’.

     Чтобы еще больше упростить процесс установки файла, предоставляется
     аргумент ‘#:install-plan’, позволяющий упаковщику указывать, какие
     файлы куда установить.  План установки представляет собой список
     ‘(SOURCE TARGET [FILTERS])’.  FILTERS необязательны.

        • Когда SOURCE соответствует файл или каталог без косой черты,
          установить его в TARGET.
             • Если TARGET имеет косую черту в конце, установить SOURCE
               basename ниже TARGET.
             • В противном случае установите SOURCE как TARGET.

        • Когда SOURCE - это каталог с косой чертой в конце или когда
          используются FILTERS, завершающая косая черта TARGET
          подразумевается с тем же значением, что и выше.
             • Без FILTER установить _содержимое_ SOURCE в TARGET.
             • С FILTERS среди ‘#:include’, ‘#:include-regexp’,
               ‘#:exclude’, ‘#:exclude-regexp’, установить только
               избранные файлы в зависимости от фильтров.  Каждый фильтр
               определяется списком строк.
                  • С помощью ‘#:include’ установите все файлы, суффикс
                    пути которых соответствует хотя бы одному из
                    элементов в данном списке.
                  • С помощью ‘#:include-regex’ установить все файлы,
                    подкаталоги которых соответствуют хотя бы одному из
                    регулярных выражений в данном списке.
                  • Фильтры ‘#:exclude’ и ‘#:exclude-regexp’ являются
                    дополнением к своим аналогам включения.  Без флагов
                    ‘#:include’ установить все файлы, кроме тех, которые
                    соответствуют фильтрам исключения.  Если указаны и
                    включения, и исключения, то исключения выполняются
                    поверх включений.
             • When a package has multiple outputs, the ‘#:output’
               argument can be used to specify which output label the
               files should be installed to.
          В любом случае пути, относительные к SOURCE, сохраняются в
          TARGET.

     Примеры:

        • ‘("foo/bar" "share/my-app/")’: Установить ‘bar’ в
          ‘share/my-app/bar’.
        • ‘("foo/bar" "share/my-app/baz")’: Установить ‘bar’ в
          ‘share/my-app/baz’.
        • ‘("foo/" "share/my-app")’: Установить содержимое ‘foo’ в
          ‘share/my-app’, например, установить ‘foo/sub/file’ в
          ‘share/my-app/sub/file’.
        • ‘("foo/" "share/my-app" #:include ("sub/file"))’: Установить
          только ‘foo/sub/file’ в ‘share/my-app/sub/file’.
        • ‘("foo/sub" "share/my-app" #:include ("file"))’: Установить
          ‘foo/sub/file’ в ‘share/my-app/file’.
        • ‘("foo/doc" "share/my-app/doc" #:output "doc")’: Install
          ‘"foo/doc"’ to ‘"share/my-app/doc"’ within the ‘"doc"’ output.

 -- Variable: vim-build-system
     This variable is exported by ‘(guix build-system vim)’.  It is an
     extension of the ‘copy-build-system’, installing Vim and Neovim
     plugins into locations where these two text editors know to find
     their plugins, using their packpaths.

     Packages which are prefixed with ‘vim-’ will be installed in Vim’s
     packpath, while those prefixed with ‘neovim-’ will be installed in
     Neovim’s packpath.  If there is a ‘doc’ directory with the plugin
     then helptags will be generated automatically.

     There are a couple of keywords added with the ‘vim-build-system’:
        • With ‘plugin-name’ it is possible to set the name of the
          plugin.  While by default this is set to the name and version
          of the package, it is often more helpful to set this to name
          which the upstream author calls their plugin.  This is the
          name used for ‘:packadd’ from inside Vim.
        • With ‘install-plan’ it is possible to augment the built-in
          install-plan of the ‘vim-build-system’.  This is particularly
          helpful if you have files which should be installed in other
          locations.  For more information about using the
          ‘install-plan’, see the ‘copy-build-system’ (*note
          ‘copy-build-system’: Системы сборки.).
        • With ‘#:vim’ it is possible to add this package to Vim’s
          packpath, in addition to if it is added automatically because
          of the ‘vim-’ prefix in the package’s name.
        • With ‘#:neovim’ it is possible to add this package to Neovim’s
          packpath, in addition to if it is added automatically because
          of the ‘neovim-’ prefix in the package’s name.
        • With ‘#:mode’ it is possible to adjust the path which the
          plugin is installed into.  By default the plugin is installed
          into ‘start’ and other options are available, including ‘opt’.
          Adding a plugin into ‘opt’ will mean you will need to run, for
          example, ‘:packadd foo’ to load the ‘foo’ plugin from inside
          of Vim.

 -- Variable: clojure-build-system
     Эта переменная экспортируется ‘(guix build-system clojure)’.  Она
     реализует простую процедуру сборки пакетов Clojure
     (https://clojure.org/) с использованием простого старого ‘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?’ определяет, нужно ли запускать тесты.

     ‘install’
          На этом этапе устанавливаются все созданные ранее jars.

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

     ‘install-doc’
          На этом этапе устанавливаются все файлы верхнего уровня с
          базовым именем, совпадающим с ‘%doc-regex’.  Другое регулярное
          выражение можно указать с помощью параметра ‘#:doc-regex’.
          Все файлы (рекурсивно) в каталогах документации, указанные в
          ‘#:doc-dirs’, также устанавливаются.

 -- Variable: cmake-build-system
     Эта переменная экспортируется ‘(guix build-system cmake)’.  Она
     реализует процедуру сборки пакетов с использованием инструмента
     сборки CMake (https://www.cmake.org).

     This build system adds the following keyword parameters to the ones
     defined by ‘gnu-build-system’:

     ‘#:cmake’
          The ‘cmake’ package is added to the set of inputs.  Which
          package is used can be specified with the ‘#:cmake’ parameter.

     ‘#:build-type’
          The ‘#:build-type’ parameter specifies in abstract terms the
          flags passed to the compiler; it defaults to
          ‘"RelWithDebInfo"’ (short for “release mode with debugging
          information”), which roughly means that code is compiled with
          ‘-O2 -g’, as is the case for Autoconf-based packages by
          default.

     ‘#:generator’
          This parameter specifies the CMake generator
          (https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html)
          responsible for writing the input files for the native build
          system.

     ‘#:test-exclude’
          Tests matching this regular expression are excluded from
          testing by ctest
          (https://cmake.org/cmake/help/latest/manual/ctest.1.html).

     ‘#:test-repeat-until-pass?’
          Directs ctest
          (https://cmake.org/cmake/help/latest/manual/ctest.1.html) to
          repeat
          (https://cmake.org/cmake/help/latest/manual/ctest.1.html#cmdoption-ctest-repeat)
          failed tests up to ‘#:test-repeat-until-pass-count’ times and
          is enabled by default.

     ‘#:test-repeat-until-pass-count’
          When ‘#:test-repeat-until-pass?’ is enabled this parameter
          sets the maximum number of failures for each test.  The
          default is ‘5’.

 -- Variable: composer-build-system
     This variable is exported by ‘(guix build-system composer)’.  It
     implements the build procedure for packages using Composer
     (https://getcomposer.org/), the PHP package manager.

     It automatically adds the ‘php’ package to the set of inputs.
     Which package is used can be specified with the ‘#:php’ parameter.

     The ‘#:test-target’ parameter is used to control which script is
     run for the tests.  By default, the ‘test’ script is run if it
     exists.  If the script does not exist, the build system will run
     ‘phpunit’ from the source directory, assuming there is a
     ‘phpunit.xml’ file.

 -- Variable: dune-build-system
     Эта переменная экспортируется в ‘(guix build-system dune)’.  Она
     поддерживает сборку пакетов с использованием Dune
     (https://dune.build/), инструмента сборки для языка
     программирования OCaml.  Она реализована как расширение
     ‘ocaml-build-system’, описанную ниже.  Таким образом, в эту систему
     сборки можно передать параметры ‘#:ocaml’ и ‘#:findlib’.

     Она автоматически добавляет пакет ‘dune’ в набор входных данных.
     Какой пакет используется, можно указать с помощью параметра
     ‘#:dune’.

     Фаза ‘configure’ отсутствует, потому что dune пакеты обычно не
     нужно настраивать.  Параметр ‘#:build-flags’ используется как
     список флагов, переданных команде ‘dune’ во время сборки.

     Параметр ‘#:jbuild?’ можно передать для использования команды
     ‘jbuild’ вместо более новой команды ‘dune’ при сборке пакета.  Его
     значение по умолчанию - ‘#f’.

     Параметр ‘#:package’ может быть передан для указания имени пакета,
     что полезно, когда пакет содержит несколько пакетов, и вы хотите
     создать только один из них.  Это эквивалентно передаче аргумента
     ‘-p’ в ‘dune’.

 -- Variable: elm-build-system
     This variable is exported by ‘(guix build-system elm)’.  It
     implements a build procedure for Elm (https://elm-lang.org)
     packages similar to ‘elm install’.

     The build system adds an Elm compiler package to the set of inputs.
     The default compiler package (currently ‘elm-sans-reactor’) can be
     overridden using the ‘#:elm’ argument.  Additionally, Elm packages
     needed by the build system itself are added as implicit inputs if
     they are not already present: to suppress this behavior, use the
     ‘#:implicit-elm-package-inputs?’ argument, which is primarily
     useful for bootstrapping.

     The ‘"dependencies"’ and ‘"test-dependencies"’ in an Elm package’s
     ‘elm.json’ file correspond to ‘propagated-inputs’ and ‘inputs’,
     respectively.

     Elm requires a particular structure for package names: *note Пакеты
     Elm:: for more details, including utilities provided by ‘(guix
     build-system elm)’.

     There are currently a few noteworthy limitations to
     ‘elm-build-system’:

        • The build system is focused on “packages” in the Elm sense of
          the word: Elm “projects” which declare ‘{ "type": "package" }’
          in their ‘elm.json’ files.  Using ‘elm-build-system’ to build
          Elm “applications” (which declare ‘{ "type": "application" }’)
          is possible, but requires ad-hoc modifications to the build
          phases.  For examples, see the definitions of the
          ‘elm-todomvc’ example application and the ‘elm’ package itself
          (because the front-end for the ‘elm reactor’ command is an Elm
          application).

        • Elm supports multiple versions of a package coexisting
          simultaneously under ‘ELM_HOME’, but this does not yet work
          well with ‘elm-build-system’.  This limitation primarily
          affects Elm applications, because they specify exact versions
          for their dependencies, whereas Elm packages specify supported
          version ranges.  As a workaround, the example applications
          mentioned above use the ‘patch-application-dependencies’
          procedure provided by ‘(guix build elm-build-system)’ to
          rewrite their ‘elm.json’ files to refer to the package
          versions actually present in the build environment.
          Alternatively, Guix package transformations (*note Defining
          Package Variants::) could be used to rewrite an application’s
          entire dependency graph.

        • We are not yet able to run tests for Elm projects because
          neither ‘elm-test-rs’
          (https://github.com/mpizenberg/elm-test-rs) nor the
          Node.js-based ‘elm-test’
          (https://github.com/rtfeldman/node-test-runner) runner has
          been packaged for Guix yet.

 -- Variable: go-build-system
     Эта переменная экспортируется ‘(guix build-system go)’.  Онf
     реализует процедуру сборки пакетов Go с использованием стандартного
     механизмов сборки Go
     (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies).

     Ожидается, что пользователь предоставит значение для ключа
     ‘#:import-path’ и, в некоторых случаях, ‘#:unpack-path’.  import
     path (https://golang.org/doc/code.html#ImportPaths) соответствует
     пути к файловой системе, ожидаемому сценариями сборки пакета и
     любыми ссылочными пакетами, и обеспечивает уникальный способ ссылки
     на Go пакет.  Обычно он основан на комбинации удаленного URI
     исходного кода пакета и иерархической структуры файловой системы.
     В некоторых случаях вам нужно будет распаковать исходный код пакета
     в другую структуру каталогов, отличную от той, которая указана в
     пути импорта, и в таких случаях следует использовать
     ‘#:unpack-path’.

     Пакеты, которые предоставляют библиотеки Go, должны устанавливать
     свой исходный код во встроенные выходные данные.  Ключ
     ‘#:install-source?’, который по умолчанию равен ‘#t’, определяет,
     установливается ли исходный код.  Для пакетов, которые
     предоставляют только исполняемые файлы, может быть установлено
     значение ‘#f’.

     Packages can be cross-built, and if a specific architecture or
     operating system is desired then the keywords ‘#:goarch’ and
     ‘#:goos’ can be used to force the package to be built for that
     architecture and operating system.  The combinations known to Go
     can be found in their documentation
     (https://golang.org/doc/install/source#environment).

     The key ‘#:go’ can be used to specify the Go compiler package with
     which to build the package.

     The phase ‘check’ provides a wrapper for ‘go test’ which builds a
     test binary (or multiple binaries), vets the code and then runs the
     test binary.  Build, test and test binary flags can be provided as
     ‘#:test-flags’ parameter, default is ‘'()’.  See ‘go help test’ and
     ‘go help testflag’ for more details.

     The key ‘#:embed-files’, default is ‘'()’, provides a list of
     future embedded files or regexps matching files.  They will be
     copied to build directory after ‘unpack’ phase.  See
     <https://pkg.go.dev/embed> for more details.

 -- Variable: 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+
          (https://developer.gnome.org/gtk3/stable /gtk-running.html).
          Это достигается путем включения программ в сценарии запуска,
          которые соответствующим образом устанавливают переменные среды
          ‘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
          (https://developer.gnome.org/gio/stable/glib-compile-schemas.html)
          в GLib скомпилированы.  Компиляция выполняется программой
          ‘glib-compile-schemas’.  Она предоставляется пакетом
          ‘glib:bin’, который автоматически импортируется системой
          сборки.  Пакет ‘glib’, предоставляющий ‘glib-compile-schemas’,
          можно указать с помощью параметра ‘#:glib’.

     Обе фазы выполняются после фазы ‘install’.

 -- Variable: guile-build-system
     Эта система сборки предназначена для пакетов Guile, которые состоят
     исключительно из кода Scheme и настолько скудны, что у них даже нет
     make-файла, не говоря уже о сценарии ‘configure’.  Она компилирует
     Scheme код с помощью ‘guild compile’ (*note (guile)Compilation::) и
     устанавливает файлы ‘.scm’ и ‘.go’ в нужное место.  Она также
     устанавливает документацию.

     Эта система сборки поддерживает кросс-компиляцию с использованием
     параметра ‘--target’ в ‘guild compile’.

     Пакеты, созданные с помощью ‘guile-build-system’, должны содержать
     пакет Guile в поле ‘native-inputs’.

 -- Variable: julia-build-system
     Эта переменная экспортируется в ‘(guix build-system julia)’.  Она
     реализует процедуру сборки, используемую пакетами julia
     (https://julialang.org/), которая по сути аналогична запуску ‘julia
     -e 'используя Pkg; Pkg.add(package)'’ в среде, где
     ‘JULIA_LOAD_PATH’ содержит пути ко всем входным данным пакета
     Julia.  Тесты запускаются с ‘Pkg.test’.

     The Julia package name and uuid is read from the file
     ‘Project.toml’.  These values can be overridden by passing the
     argument ‘#:julia-package-name’ (which must be correctly
     capitalized) or ‘#:julia-package-uuid’.

     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
     (*note Фазы сборки::) 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") "\")\n"))))
                        ;; There's a Julia file for each platform, override them all.
                        (find-files "src/wrappers/" "\\.jl$"))))

     Some older packages that aren’t using ‘Project.toml’ yet, will
     require this file to be created, too.  It is internally done if the
     arguments ‘#:julia-package-name’ and ‘#:julia-package-uuid’ are
     provided.

 -- Variable: maven-build-system
     Эта переменная экспортируется в ‘(guix build-system maven)’.  Она
     реализует процедуру сборки пакетов Maven
     (https://maven.apache.org).  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)’, которое также экспортируется.

 -- Variable: minetest-mod-build-system
     This variable is exported by ‘(guix build-system minetest)’.  It
     implements a build procedure for Minetest
     (https://www.minetest.net) mods, which consists of copying Lua
     code, images and other resources to the location Minetest searches
     for mods.  The build system also minimises PNG images and verifies
     that Minetest can load the mod without errors.

 -- Variable: minify-build-system
     Эта переменная экспортируется в ‘(guix build-system minify)’.  Она
     реализует процедуру минификации для простых пакетов JavaScript.

     Он добавляет ‘uglify-js’ к набору входных данных и использует его
     для сжатия всех файлов JavaScript в каталоге ‘src’.  Другой
     minifier пакет можно указать с помощью параметра ‘#:uglify-js’, но
     ожидается, что этот пакет запишет минимизированный код в
     стандартный вывод.

     Когда не все входные файлы JavaScript находятся в каталоге ‘src’,
     можно использовать параметр ‘#:javascript-files’, чтобы указать
     список имен файлов для передачи в minifier.

 -- Variable: mix-build-system
     This is a variable exported by ‘guix build-system mix’.  It
     implements the standard build procedure used by Elixr programs with
     Mix (https://hexdocs.pm/mix/Mix.html), which consists of running
     ‘mix compile’, thereby creating bytecode.

     The API is similar to the GNU-BUILD-SYSTEM, with some specifics for
     Elixir:
        • ‘#:tests?’ is a boolean, ‘#true’ by default, determining
          whether tests for the current build have to be run or not.
        • ‘#:test-flags’ is a list of arguments append to the ‘mix test’
          invocation.  It defaults to ‘'()’.
        • ‘#:mix-exs’, changes the full path to the ‘mix.exs’ file.  It
          defaults to ‘"mix.exs"’.  Please refer to upstream
          (https://hexdocs.pm/mix/Mix.html#module-environment-variables)
          documentation for more details.
        • ‘#:mix-path’, appends extra code paths.  It defaults to ‘#f’.
          Please refer to upstream
          (https://hexdocs.pm/mix/Mix.html#module-environment-variables)
          documentation for more details.

 -- Variable: mozilla-build-system
     This variable is exported by ‘(guix build-system mozilla)’.  It
     sets the ‘--target’ and ‘--host’ configuration flags to what
     software developed by Mozilla expects – due to historical reasons,
     Mozilla software expects ‘--host’ to be the system that is
     cross-compiled from and ‘--target’ to be the system that is
     cross-compiled to, contrary to the standard Autotools conventions.

 -- Variable: ocaml-build-system
     Эта переменная экспортируется в ‘(guix build-system ocaml)’.  Она
     реализует процедуру сборки пакетов OCaml (https://ocaml.org),
     которая заключается в выборе правильного набора команд для запуска
     для каждого пакета.  Пакеты OCaml могут ожидать выполнения
     множества различных команд.  Эта система сборки попробует некоторые
     из них.

     Если в пакете есть файл ‘setup.ml’ на верхнем уровне, он будет
     запускать ‘ocaml setup.ml -configure’, ‘ocaml setup.ml -build’ и
     ‘ocaml setup.ml -install’.  Система сборки предполагает, что этот
     файл был сгенерирован OASIS (http://oasis.forge.ocamlcore.org/), и
     позаботится об установке префикса и включении тестов, если они не
     отключены.  Вы можете передать флаги конфигурации и сборки с
     помощью ‘#: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’.

 -- Variable: python-build-system
     Эта переменная экспортируется в ‘(guix build-system python)’.  Она
     реализует более или менее стандартную процедуру сборки,
     используемую пакетами Python, которая заключается в запуске ‘python
     setup.py build’, а затем ‘python setup.py install
     --prefix=/gnu/store/...’.

     For packages that install stand-alone Python programs under ‘bin/’,
     it takes care of wrapping these programs so that their
     ‘GUIX_PYTHONPATH’ environment variable points to all the Python
     libraries they depend on.

     Какой пакет Python используется для сборки, можно указать с помощью
     параметра ‘#:python’.  Это полезный способ принудительно создать
     пакет для определенной версии интерпретатора Python, что может
     потребоваться, если пакет совместим только с одной версией
     интерпретатора.

     По умолчанию guix вызывает ‘setup.py’ под управлением ‘setuptools’,
     как и ‘pip’.  Некоторые пакеты несовместимы с setuptools (и pip),
     поэтому вы можете отключить это, установив для параметра
     ‘#:use-setuptools?’ значение ‘#f’.

     If a ‘"python"’ output is available, the package is installed into
     it instead of the default ‘"out"’ output.  This is useful for
     packages that include a Python package as only a part of the
     software, and thus want to combine the phases of
     ‘python-build-system’ with another build system.  Python bindings
     are a common usecase.

 -- Variable: pyproject-build-system
     This is a variable exported by ‘guix build-system pyproject’.  It
     is based on PYTHON-BUILD-SYSTEM, and adds support for
     ‘pyproject.toml’ and PEP 517 (https://peps.python.org/pep-0517/).
     It also supports a variety of build backends and test frameworks.

     The API is slightly different from PYTHON-BUILD-SYSTEM:
        • ‘#:use-setuptools?’ and ‘#:test-target’ is removed.
        • ‘#:configure-flags’ is changed.  Instead of a list this option
          must be a JSON object, whose interpretation depends on the
          build backend.  For instance the example from PEP 517
          (https://peps.python.org/pep-0517/#config-settings) should be
          written as ‘'(@ ("CC" "gcc") ("--global-option"
          ("--some-global-option")) ("--build-option" ("--build-option1"
          "--build-option2")))’
        • ‘#:backend-path’ is added.  It defaults to ‘#false’, but when
          set to a list it will be appended to Python’s search path and
          overrides the definition in ‘pyproject.toml’.
        • ‘#:build-backend’ is added.  It defaults to ‘#false’ and will
          try to guess the appropriate backend based on
          ‘pyproject.toml’.
        • ‘#:test-backend’ is added.  It defaults to ‘#false’ and will
          guess an appropriate test backend based on what is available
          in package inputs.
        • ‘#:test-flags’ is added.  The default is ‘'()’.  These flags
          are passed as arguments to the test command.  Note that flags
          for verbose output is always enabled on supported backends.

     It is considered “experimental” in that the implementation details
     are not set in stone yet, however users are encouraged to try it
     for new Python projects (even those using ‘setup.py’).  The API is
     subject to change, but any breaking changes in the Guix channel
     will be dealt with.

     Eventually this build system will be deprecated and merged back
     into PYTHON-BUILD-SYSTEM, probably some time in 2024.

 -- 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’.

 -- Variable: renpy-build-system
     Эта переменная экспортируется в ‘(guix build-system python)’.  Она
     реализует более или менее стандартную процедуру сборки,
     используемую пакетами Python, которая заключается в запуске ‘python
     setup.py build’, а затем ‘python setup.py install
     --prefix=/gnu/store/...’.

     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’.

 -- Variable: 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’.

 -- Variable: r-build-system
     Эта переменная экспортируется в ‘(guix build-system r)’.  Она
     реализует процедуру сборки, используемую пакетами R
     (https://r-project.org), которая, по сути, немного больше, чем
     запуск ‘R CMD INSTALL --library=/gnu/store/...’ в среде, где
     ‘R_LIBS_SITE’ содержит пути ко всем входам пакета R. Тесты
     запускаются после установки с использованием R-функции
     ‘tools::testInstalledPackage’.

 -- Variable: rakudo-build-system
     Эта переменная экспортируется ‘(guix build-system rakudo)’.
     Которая реализует систем сборки, используемую Rakudo
     (https://rakudo.org/) для Perl6 (https://perl6.org/) пакетов.  Она
     устанавливает: пакет в ‘/gnu/store/.../NAME-VERSION/share/perl6’;
     двоичные файлы, библиотеки и ресурсы; помещает файлы в ‘bin/’.
     Тесты можно пропустить, передав ‘#f’ параметру ‘tests?’.

     Какой пакет rakudo используется, можно указать с помощью ‘rakudo’.
     Какой пакет perl6-tap-harness, используемый для тестов, можно
     указать с помощью ‘#:verify6’ или удалить, передав ‘#f’ в параметр
     ‘with-verify6?’.  Какой пакет perl6-zef, используемый для
     тестирования и установки, можно указать с помощью ‘#:zef’ или
     удалить, передав ‘#f’ в параметр ‘with-zef?’.

 -- Variable: rebar-build-system
     This variable is exported by ‘(guix build-system rebar)’.  It
     implements a build procedure around rebar3 (https://rebar3.org), a
     build system for programs written in the Erlang language.

     It adds both ‘rebar3’ and the ‘erlang’ to the set of inputs.
     Different packages can be specified with the ‘#:rebar’ and
     ‘#:erlang’ parameters, respectively.

     This build system is based on ‘gnu-build-system’, but with the
     following phases changed:

     ‘unpack’
          This phase, after unpacking the source like the
          ‘gnu-build-system’ does, checks for a file ‘contents.tar.gz’
          at the top-level of the source.  If this file exists, it will
          be unpacked, too.  This eases handling of package hosted at
          <https://hex.pm/>, the Erlang and Elixir package repository.

     ‘bootstrap’
     ‘configure’
          There are no ‘bootstrap’ and ‘configure’ phase because erlang
          packages typically don’t need to be configured.

     ‘build’
          This phase runs ‘rebar3 compile’ with the flags listed in
          ‘#:rebar-flags’.

     ‘check’
          Unless ‘#:tests? #f’ is passed, this phase runs ‘rebar3
          eunit’, or some other target specified with ‘#:test-target’,
          with the flags listed in ‘#:rebar-flags’,

     ‘install’
          This installs the files created in the default profile, or
          some other profile specified with ‘#:install-profile’.

 -- Variable: texlive-build-system
     Эта переменная экспортируется в ‘(guix build-system texlive)’.  Она
     используется для сборки пакетов TeX в batch режиме с указанным
     движком.  Система сборки устанавливает переменную ‘TEXINPUTS’ для
     поиска всех исходных файлов TeX во входных данных.

     By default it tries to run ‘luatex’ on all ‘.ins’ files, and if it
     fails to find any, on all ‘.dtx’ files.  A different engine and
     format can be specified with, respectively, the ‘#:tex-engine’ and
     ‘#:tex-format’ arguments.  Different build targets can be specified
     with the ‘#:build-targets’ argument, which expects a list of file
     names.

     It also generates font metrics (i.e., ‘.tfm’ files) out of Metafont
     files whenever possible.  Likewise, it can also create TeX formats
     (i.e., ‘.fmt’ files) listed in the ‘#:create-formats’ argument, and
     generate a symbolic link from ‘bin/’ directory to any script
     located in ‘texmf-dist/scripts/’, provided its file name is listed
     in ‘#:link-scripts’ argument.

     The build system adds ‘texlive-bin’ from ‘(gnu packages tex)’ to
     the native inputs.  It can be overridden with the ‘#:texlive-bin’
     argument.

     The package ‘texlive-latex-bin’, from the same module, contains
     most of the tools for building TeX Live packages; for convenience,
     it is also added by default to the native inputs.  However, this
     can be troublesome when building a dependency of
     ‘texlive-latex-bin’ itself.  In this particular situation, the
     ‘#:texlive-latex-bin?’ argument should be set to ‘#f’.

 -- Variable: 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’.

 -- Variable: waf-build-system
     Эта переменная экспортируется в ‘(guix build-system waf)’.  Она
     реализует процедуру сборки вокруг сценария ‘waf’.  Общие
     этапы—‘configure’, ‘build’ и ‘install’—реализуются путем передачи
     их имен в качестве аргументов сценарию ‘waf’.

     Скрипт ‘waf’ выполняется интерпретатором Python.  Какой пакет
     Python используется для запуска сценария, можно указать с помощью
     параметра ‘#:python’.

 -- Variable: zig-build-system
     This variable is exported by ‘(guix build-system zig)’.  It
     implements the build procedures for the Zig (https://ziglang.org/)
     build system (‘zig build’ command).

     Selecting this build system adds ‘zig’ to the package inputs, in
     addition to the packages of ‘gnu-build-system’.

     This build system by default installs package source to output.
     This behavior can be disabled by setting ‘#:install-source?’
     parameter to ‘#f’.

     For packages that don’t install anything and don’t come with a test
     suite (likely library packages to be used by other Zig packages),
     you can set ‘#:skip-build?’ parameter to ‘#t’, which skips ‘build’
     and ‘check’ phases.

     The ‘configure’ phase sets up environment for ‘zig build’.  You
     need to add custom phases after it if you want to invoke ‘zig’.

     The ‘#:zig-build-flags’ parameter is a list of flags that are
     passed to ‘zig build’ in ‘build’ phase.  The ‘#:zig-test-flags’
     parameter is a list of flags that are passed to ‘zig build test’ in
     ‘check’ phase.  The default compiler package can be overridden with
     the ‘#:zig’ parameter.

     The optional ‘#:zig-release-type’ parameter declares the type of
     release.  Possible values are: ‘"safe"’, ‘"fast"’, or ‘"small"’.
     The default value is ‘#f’, which causes the release flag to be
     omitted from the ‘zig’ command and results in a ‘"debug"’ build.

 -- Variable: scons-build-system
     Эта переменная экспортируется в ‘(guix build-system scons)’.  Она
     реализует процедуру сборки, используемую инструментом сборки
     программного обеспечения SCons.  Эта система сборки запускает
     ‘scons’ для сборки пакета, ‘scons test’ для запуска тестов и затем
     ‘scons install’ для установки пакета.

     Дополнительные флаги, передаваемые в ‘scons’, можно указать с
     помощью параметра ‘#:scons-flags’.  Цели сборки и установки по
     умолчанию могут быть переопределены с помощью ‘#:build-target’ и
     ‘#:install-target’ соответственно.  Версия Python, используемая для
     запуска SCons, может быть указана путем выбора соответствующего
     пакета SCons с параметром ‘#:scons’.

 -- Variable: hare-build-system
     This variable is exported by ‘(guix build-system hare)’.  It
     implements the Makefile build process typically used by Hare
     packages, removing the ‘configure’ phase used by ‘gnu-build-system’
     and modifying existing phases to set the Hare architecture tag,
     module path, and package install destinations appropriately.

     This relies on the package’s Makefile supporting, at minimum, the
     variables ‘HAREFLAGS’ and ‘THIRDPARTYDIR’.  Packages may set
     ‘make-flags’ to override or supplement these variables.

     By default, Hare modules are installed to the ‘lib’ output if it
     exists, and all other files to the ‘bin’ output.  If an output does
     not exist, the default ‘out’ output is used instead.  This behavior
     may be overriden through the ‘#:binary-output’ and
     ‘#:module-output’ keyword arguments.

     ‘(guix build-system hare)’ also provides utility definitions for
     creating Hare packages.  The variable ‘%hare-supported-systems’ is
     the list of build targets currently supported by ‘hare’, for use in
     ‘supported-systems’ (*note ссылка на пакет::).  The procedure
     ‘target->hare-arch’ may be used to get the Hare architecture tag
     for a given (supported) Guix target or system.

 -- Variable: 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’.

 -- Variable: dub-build-system
     Эта переменная экспортируется в ‘(guix build-system dub)’.  Она
     реализует процедуру сборки Dub, используемую пакетами D, которая
     включает запуск ‘dub build’ и ‘dub run’.  Установка осуществляется
     путем копирования файлов вручную.

     Какой компилятор D используется, можно указать с помощью параметра
     ‘#:ldc’, который по умолчанию равен ‘ldc’.

 -- Variable: emacs-build-system
     Эта переменная экспортируется в ‘(guix build-system emacs)’.  Она
     реализует процедуру установки, аналогичную системе упаковки самого
     Emacs (*note (emacs)Packages::).

     Сначала она создает файл ‘package-autoloads.el’, а затем
     байт-компилирует все файлы Emacs Lisp.  В отличие от системы
     упаковки Emacs, файлы документации Info перемещаются в стандартный
     каталог документации, а файл ‘dir’ удаляется.  Файлы пакета Elisp
     устанавливаются непосредственно в ‘share/emacs/site-lisp’.

 -- Variable: font-build-system
     Эта переменная экспортируется в ‘(guix build-system font)’.  Она
     реализует процедуру установки для пакетов шрифтов, в которой
     upstream предоставляет предварительно скомпилированные файлы
     TrueType, OpenType и т.д. файлы шрифтов, которые необходимо просто
     скопировать на место.  Она копирует файлы шрифтов в стандартные
     места выходного каталога.

 -- Variable: meson-build-system
     Эта переменная экспортируется в ‘(guix build-system meson)’.  Она
     реализует процедуру сборки для пакетов, которые используют Meson
     (https://mesonbuild.com) в качестве своей системы сборки.

     Она добавляет к набору входов как Meson, так и Ninja
     (https://ninja-build.org/), при необходимости их можно изменить с
     помощью параметров ‘#:meson’ и ‘#:ninja’.

     Эта система сборки является расширением ‘gnu-build-system’, но со
     следующими фазами, измененными на некоторые специфичные для Meson:

     ‘configure’
          На этапе выполняется ‘meson’ с флагами, указанными в
          ‘#:configure-flags’.  Флаг ‘--buildtype’ всегда установлен на
          ‘debugoptimized’, если что-то еще не указано в ‘#:build-type’.

     ‘build’
          На этапе выполняется ‘ninja’ для параллельной сборки пакета по
          умолчанию, но это можно изменить с помощью
          ‘#:parallel-build?’.

     ‘check’
          The phase runs ‘meson test’ with a base set of options that
          cannot be overridden.  This base set of options can be
          extended via the ‘#:test-options’ argument, for example to
          select or skip a specific test suite.

     ‘install’
          Фаза выполняется ‘ninja install’ и не может быть изменен.

     Помимо этого, система сборки также добавляет следующие фазы:

     ‘fix-runpath’
          This phase ensures that all binaries can find the libraries
          they need.  It searches for required libraries in
          subdirectories of the package being built, and adds those to
          ‘RUNPATH’ where needed.  It also removes references to
          libraries left over from the build phase by ‘meson’, such as
          test dependencies, that aren’t actually required for the
          program to run.

     ‘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?’.

 -- Variable: linux-module-build-system
     ‘linux-module-build-system’ позволяет создавать модули ядра Linux.

     Эта система сборки является расширением ‘gnu-build-system’, но со
     следующими изменениями:

     ‘configure’
          На этой фазе среда настраивается таким образом, чтобы Makefile
          ядра Linux можно было использовать для сборки внешнего модуля
          ядра.

     ‘build’
          На этой фазе используется Makefile ядра Linux для сборки
          внешнего модуля ядра.

     ‘install’
          На этой фазе используется Makefile ядра Linux для установки
          внешнего модуля ядра.

     Возможно и полезно указать ядро Linux, которое будет использоваться
     для сборки модуля (в форме ‘arguments’ пакета с использованием
     ‘linux-module-build-system’ используйте ключ ‘#:linux’, чтобы
     указать это).

 -- Variable: node-build-system
     Эта переменная экспортируется в ‘(guix build-system node)’.  Она
     реализует процедуру сборки, используемую Node.js
     (https://nodejs.org), которая реализует аппроксимацию команды ‘npm
     install’, за которой следует команда ‘npm test’.

     Какой пакет Node.js используется для интерпретации команд ‘npm’,
     можно указать с помощью параметра ‘#:node’, который по умолчанию
     равен ‘node’.

 -- Variable: tree-sitter-build-system

     This variable is exported by ‘(guix build-system tree-sitter)’.  It
     implements procedures to compile grammars for the Tree-sitter
     (https://tree-sitter.github.io/tree-sitter/) parsing library.  It
     essentially runs ‘tree-sitter generate’ to translate ‘grammar.js’
     grammars to JSON and then to C. Which it then compiles to native
     code.

     Tree-sitter packages may support multiple grammars, so this build
     system supports a ‘#:grammar-directories’ keyword to specify a list
     of locations where a ‘grammar.js’ file may be found.

     Grammars sometimes depend on each other, such as C++ depending on C
     and TypeScript depending on JavaScript.  You may use inputs to
     declare such dependencies.

   Наконец, для пакетов, которым не нужно ничего столь же сложного,
предоставляется “trivial” система сборки.  Она тривиальна в том смысле,
что она практически не оказывает поддержки при сборке: она не извлекает
никаких неявных входных данных и не имеет понятия о этапах сборки.

 -- Variable: trivial-build-system
     Эта переменная экспортируется ‘(guix build-system trivial)’.

     Эта система сборки требует аргумента ‘#:builder’.  Этот аргумент
     должен быть Scheme выражением, которое строит выходные данные
     пакета—как с ‘build-expression->derivation’ (*note
     ‘build-expression->derivation’: Деривации.).

 -- Variable: channel-build-system
     This variable is exported by ‘(guix build-system channel)’.

     This build system is meant primarily for internal use.  A package
     using this build system must have a channel specification as its
     ‘source’ field (*note Каналы::); alternatively, its source can be a
     directory name, in which case an additional ‘#:commit’ argument
     must be supplied to specify the commit being built (a hexadecimal
     string).

     Optionally, a ‘#:channels’ argument specifying additional channels
     can be provided.

     The resulting package is a Guix instance of the given channel(s),
     similar to how ‘guix time-machine’ would build it.

