1.1 Gerenciando software do jeito do Guix

O Guix fornece uma interface de gerenciamento de pacotes de linha de comando (veja Gerenciamento de pacote), ferramentas para ajudar no desenvolvimento de software (veja Desenvolvimento), utilitários de linha de comando para uso mais avançado (veja Utilitários), bem como interfaces de programação Scheme (veja Interface de programação). O build daemon é responsável por compilar pacotes em nome dos usuários (veja Configurando o daemon) e por baixar binários pré-compilados de fontes autorizados (veja Substitutos).

Guix inclui definições de pacotes para muitos pacotes GNU e não-GNU, todos os quais respeitam a liberdade de computação do usuário. É extensível: os usuários podem escrever suas próprias definições de pacotes (veja Definindo pacotes) e disponibilizá-los como módulos de pacotes independentes (veja Módulos de pacote). Também é personalizável: os usuários podem derivar definições de pacotes especializados das existentes, incluindo da linha de comando (veja Opções de transformação de pacote).

Nos bastidores, a Guix implementa a disciplina gerenciamento de pacotes funcional pioneira da Nix (veja Agradecimentos). No Guix, o processo de compilação e instalação de pacotes é visto como uma função, no sentido matemático. Essa função recebe entradas, como scripts de compilação, um compilador e bibliotecas, e retorna um pacote instalado. Como uma função pura, seu resultado depende apenas de suas entradas – por exemplo, não pode fazer referência a um software ou scripts que não foram explicitamente passados como entradas. Uma função de compilação sempre produz o mesmo resultado ao passar por um determinado conjunto de entradas. Não pode alterar o ambiente do sistema em execução de qualquer forma; por exemplo, ele não pode criar, modificar ou excluir arquivos fora de seus diretórios de compilação e instalação. Isto é conseguido através da execução de processos de compilação em ambientes isolados (ou containers), onde somente suas entradas explícitas são visíveis.

O resultado das funções de compilação do pacote é mantido (cached) no sistema de arquivos, em um diretório especial chamado armazém (veja O armazém). Cada pacote é instalado em um diretório próprio no armazém – por padrão, em /gnu/store. O nome do diretório contém um hash de todas as entradas usadas para compilar esse pacote; Assim, a alteração uma entrada gera um nome de diretório diferente.

Essa abordagem é a fundação para os principais recursos do Guix: suporte para atualização transacional de pacotes e reversão, instalação por usuário e coleta de lixo de pacotes (veja Recursos).

1.2 Distribuição GNU

O Guix vem com uma distribuição do sistema GNU que consiste inteiramente de software livre³. A distribuição pode ser instalada por conta própria (veja Instalação do sistema), mas também é possível instalar o Guix como um gerenciador de pacotes em cima de um sistema GNU/Linux instalado (veja Instalação). Quando precisamos distinguir entre os dois, nos referimos à distribuição independente como Guix System.

A distribuição fornece pacotes GNU principais, como GNU libc, GCC e Binutils, além de muitos aplicativos GNU e não GNU. A lista completa de pacotes disponíveis pode ser acessada online ou executando guix package (veja Invocando guix package):

guix package --list-available

Nosso objetivo é fornecer uma distribuição prática e 100% de software livre, baseada em Linux e outras variantes do GNU, com foco na promoção e forte integração de componentes do GNU e ênfase em programas e ferramentas que ajudam os usuários a exercer essa liberdade.

Os pacotes estão atualmente disponíveis nas seguintes plataformas:

x86_64-linux

Arquitetura Intel/AMD x86_64, kernel Linux-Libre.

i686-linux

Arquitetura Intel de 32 bits (IA32), kernel Linux-Libre.

armhf-linux

Arquitetura ARMv7-A com hard float, Thumb-2 e NEON, usando a interface binária de aplicativos EABI hard-float (ABI) e o kernel Linux-Libre.

aarch64-linux

Processadores ARMv8-A little-endian de 64 bits, kernel Linux-Libre.

i586-gnu

GNU/Hurd sobre a arquitetura Intel de 32 bits (IA32).

Esta configuração é experimental e está em desenvolvimento. A maneira mais fácil de você tentar é configurando uma instância de hurd-vm-service-type na sua máquina GNU/Linux (veja hurd-vm-service-type). Veja Contribuindo, sobre como ajudar!

x86_64-gnu

GNU/Hurd on the x86_64 Intel/AMD 64-bit architecture.

This configuration is even more experimental and under heavy upstream development.

mips64el-linux (sem suporte)

processadores little-endian MIPS de 64 bits, especificamente a série Loongson, n32 ABI e kernel Linux-Libre. Esta configuração não é mais totalmente suportada; em particular, não há trabalho em andamento para garantir que esta arquitetura ainda funcione. Caso alguém decida que deseja reviver esta arquitetura, o código ainda estará disponível.

powerpc-linux (sem suporte)

processadores PowerPC big-endian de 32 bits, especificamente o PowerPC G4 com suporte AltiVec e kernel Linux-Libre. Esta configuração não é totalmente suportada e não há trabalho em andamento para garantir que esta arquitetura funcione.

powerpc64le-linux

processadores little-endian 64 bits Power ISA, kernel Linux-Libre. Isso inclui sistemas POWER9 como o placa-mãe RYF Talos II. Esta plataforma está disponível como uma "prévia de tecnologia": embora seja suportada, substitutos ainda não estão disponíveis na fazenda de construção (veja Substitutos), e alguns pacotes podem falhar na construção (veja Rastreando Bugs e Mudanças). Dito isso, a comunidade Guix está trabalhando ativamente para melhorar esse suporte, e agora é um ótimo momento para experimentá-lo e se envolver!

riscv64-linux

processadores little-endian RISC-V de 64 bits, especificamente RV64GC, e kernel Linux-Libre. Esta plataforma está disponível como uma "prévia de tecnologia": embora seja suportada, substitutos ainda não estão disponíveis na build farm (veja Substitutos), e alguns pacotes podem falhar na compilação (veja Rastreando Bugs e Mudanças). Dito isto, a comunidade Guix está trabalhando ativamente para melhorar este suporte, e agora é um ótimo momento para experimentá-lo e se envolver!

Com o Guix System, você declara todos os aspectos da configuração do sistema operacional, e o Guix cuida de instanciar a configuração de maneira transacional, reproduzível e sem estado (veja Configuração do sistema). O Guix System usa o kernel Linux-libre, o sistema de inicialização Shepherd (veja Introduction em The GNU Shepherd Manual), os conhecidos utilitários do GNU e cadeia de ferramentas, bem como o ambiente gráfico ou os serviços de sistema do sua escolha.

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

Para obter informações sobre como portar para outras arquiteturas ou kernels, veja Portando para uma nova plataforma.

A construção desta distribuição é um esforço cooperativo e você está convidado a participar! Veja Contribuindo, para obter informações sobre como você pode ajudar.

2.1 Instalação de binários

This section describes how to install Guix from a self-contained tarball providing binaries for Guix and for all its dependencies. This is often quicker than installing from source, described later (veja Compilando do git).

Importante: Esta seção se aplica somente a sistemas sem Guix. Segui-la para instalações Guix existentes sobrescreverá arquivos importantes do sistema.

Algumas distribuições GNU/Linux, como Debian, Ubuntu e openSUSE fornecem Guix por meio de seus próprios gerenciadores de pacotes. A versão do Guix pode ser mais antiga que 4538aa4, mas você pode atualizá-la depois executando ‘guix pull’.

Aconselhamos os administradores de sistema que instalam o Guix, tanto a partir do script de instalação quanto por meio do gerenciador de pacotes nativo de sua distribuição estrangeira, a também ler e seguir regularmente os avisos de segurança, conforme mostrado pelo guix pull.

Para Debian ou derivados como Ubuntu ou Trisquel, chame:

sudo apt install guix

Da mesma forma, no openSUSE:

sudo zypper install guix

Se você estiver executando o Parabola, depois de habilitar o repositório pcr (Parabola Community Repo), você pode instalar o Guix com:

sudo pacman -S guix

O projeto Guix também fornece um script de shell, guix-install.sh, que automatiza o processo de instalação binária sem o uso de um gerenciador de pacotes de distro estrangeiro⁵. O uso de guix-install.sh requer Bash, GnuPG, GNU tar, wget e Xz.

The script guides you through the following:

• Baixando e extraindo o tarball binário
• Setting up the build daemon
• Disponibilizando o comando ‘guix’ para usuários não root
• Configuring substitute servers

Como root, execute:

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

O script para instalar o Guix também está empacotado no Parabola (no repositório pcr). Você pode instalá-lo e executá-lo com:

sudo pacman -S guix-installer
sudo guix-install.sh

Nota: Por padrão, guix-install.sh configurará o Guix para baixar binários de pacotes pré-construídos, chamados substitutes (veja Substitutos), das fazendas de construção do projeto. Se você escolher não permitir isso, o Guix construirá tudo a partir da fonte, tornando cada instalação e atualização muito cara. Veja Confiança em binários para uma discussão sobre por que você pode querer construir pacotes a partir da fonte.

Para usar substitutos de bordeaux.guix.gnu.org, ci.guix.gnu.org ou um espelho, você deve autorizá-los. Por exemplo,

# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/bordeaux.guix.gnu.org.pub
# guix archive --authorize < \
     ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub

Quando terminar de instalar o Guix, veja Configuração de aplicativo para configurações extras que você pode precisar e Começando para seus primeiros passos!

Nota: O tarball da instalação binária pode ser (re)produzido e verificado simplesmente executando o seguinte comando na árvore de código-fonte do Guix:

make guix-binary.sistema.tar.xz

... que, por sua vez, executa:

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

Veja Invocando guix pack, para mais informações sobre essa ferramenta útil.

Caso você queira desinstalar o Guix, execute o mesmo script com o sinalizador --uninstall:

./guix-install.sh --uninstall

Com --uninstall, o script exclui irreversivelmente todos os arquivos Guix, configuração e serviços.

2.2 Configurando o daemon

Durante a instalação, o build daemon que deve estar em execução para usar o Guix já foi configurado e você pode executar comandos guix no seu programa de terminal, veja Começando:

guix build hello

Se isso ocorrer sem erros, sinta-se à vontade para pular esta seção. Você deve continuar com a seção seguinte, Configuração de aplicativo.

No entanto, agora seria um bom momento para substituir versões desatualizadas do daemon, ajustá-lo, executar compilações em outras máquinas (veja Usando o recurso de descarregamento) ou iniciá-lo manualmente em ambientes especiais como “chroots” (veja Acessando um sistema existente via chroot) ou WSL (não necessário para imagens WSL criadas com Guix, veja wsl2-image-type). Se você quiser saber mais ou otimizar seu sistema, vale a pena ler esta seção.

Operações como compilar um pacote ou executar o coletor de lixo são todas executadas por um processo especializado, o build daemon, em nome dos clientes. Apenas o daemon pode acessar o armazém e seu banco de dados associado. Assim, qualquer operação que manipule o armazém passa pelo daemon. Por exemplo, ferramentas de linha de comando como guix package e guix build se comunicam com o daemon (via chamadas de procedimento remoto) para instruir o que fazer.

As seções a seguir explicam como preparar o ambiente do daemon de compilação. Veja Substitutos para informações sobre como permitir que o daemon baixe binários pré-compilados.

• Configuração do ambiente de compilação
• Usando o recurso de descarregamento
• Suporte a SELinux

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)   \
            -c "Guix build user $i" --system    \
            guixbuilder$i;
  done

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

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

      (build-machine
        (name "armeight.example.org")
        (systems (list "aarch64-linux"))
        (host-key "ssh-rsa AAAAB3Nza…")
        (user "alice")

        ;; Lembre-se de que 'guix offload' é gerado por
        ;; 'guix-daemon' como root.
        (private-key "/root/.ssh/identity-for-guix")))

ssh build-machine guix repl --version

# guix archive --generate-key

# guix archive --authorize < master-public-key.txt

# guix offload test

# guix offload test machines-qualif.scm

# guix offload test machines.scm '\.gnu\.org$'

# guix offload status

semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil

mount -o remount,rw /gnu/store
restorecon -R /gnu /var/guix

systemctl restart guix-daemon

ps -Zax | grep guix-daemon

2.3 Invocando guix-daemon

O programa guix-daemon implementa todas as funcionalidades para acessar o armazém. Isso inclui iniciar processos de compilação, executar o coletor de lixo, consultar a disponibilidade de um resultado da compilação etc. É normalmente executado como root, assim:

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

Este daemon também pode ser iniciado seguindo o protocolo de “ativação de soquete” do systemd (veja make-systemd-constructor em The GNU Shepherd Manual).

Para detalhes sobre como configurá-lo, veja Configurando o daemon.

Por padrão, guix-daemon inicia processos de compilação sob diferentes UIDs, obtidos do grupo de compilação especificado com --build-users-group. Além disso, cada processo de compilação é executado em um ambiente chroot que contém apenas o subconjunto do armazém do qual o processo de compilação depende, conforme especificado por sua derivação (veja derivação), mais um conjunto de diretórios de sistema específicos. Por padrão, o último contém /dev e /dev/pts. Além disso, no GNU/Linux, o ambiente de compilação é um container: além de ter sua própria árvore de sistema de arquivos, ele tem um espaço de nome de montagem separado, seu próprio espaço de nome PID, espaço de nome de rede, etc. Isso ajuda a obter compilações reproduzíveis (veja Recursos).

Quando o daemon executa uma compilação em nome do usuário, ele cria um diretório de compilação em /tmp ou no diretório especificado por sua variável de ambiente TMPDIR. Esse diretório é compartilhado com o contêiner durante a compilação, embora dentro do contêiner, a árvore de compilação seja sempre chamada de /tmp/guix-build-name.drv-0.

O diretório de compilação é excluído automaticamente após a conclusão, a menos que a compilação falhe e o cliente tenha especificado --keep-failed (veja --keep-failed).

O daemon escuta conexões e gera um subprocesso para cada sessão iniciada por um cliente (um dos subcomandos guix). O comando guix processes permite que você tenha uma visão geral da atividade no seu sistema visualizando cada uma das sessões e clientes ativos. Veja Invocando guix processes, para mais informações.

As seguintes opções de linha de comando são suportadas:

--build-users-group=grupo

Obtém os usuários do grupo para executar os processos de compilação (veja usuários de compilação).

--no-substitutes ¶

Não use substitutos para compilar produtos. Ou seja, sempre crie coisas localmente, em vez de permitir downloads de binários pré-compilados (veja Substitutos).

Quando o daemon é executado com --no-substitutes, os clientes ainda podem habilitar explicitamente a substituição por meio da chamada de procedimento remoto set-build-options (veja O armazém).

--substitute-urls=urls

Consider urls the default whitespace-separated list of substitute source URLs. When this option is omitted, ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org’ is used.

Isso significa que os substitutos podem ser baixados de urls, desde que assinados por uma assinatura confiável (veja Substitutos).

Veja Obtendo substitutos de outros servidores, para mais informações sobre como configurar o daemon para obter substitutos de outros servidores.

--no-offload

Não use compilações de offload para outras máquinas (veja Usando o recurso de descarregamento). Ou seja, sempre compile as coisas localmente em vez de descarregar compilações para máquinas remotas.

--cache-failures

Armazena em cache as compilações que falharam. Por padrão, apenas compilações bem-sucedidas são armazenadas em cache.

Quando essa opção é usada, o guix gc --list-failures pode ser usado para consultar o conjunto de itens do armazém marcados como com falha; O guix gc --clear-failures remove os itens do armazém do conjunto de falhas em cache. Veja Invocando guix gc.

--cores=n

-c n

Usa n núcleos de CPU para compilar cada derivação; 0 significa todos disponíveis.

O valor padrão é 0, mas pode ser substituído pelos clientes, como a opção --cores de guix build (veja Invocando guix build).

O efeito é definir a variável de ambiente NIX_BUILD_CORES no processo de compilação, que pode então usá-la para explorar o paralelismo interno — por exemplo, executando make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Permite no máximo n tarefas de compilação em paralelo. O valor padrão é 1. Definir como 0 significa que nenhuma compilação será executada localmente; em vez disso, o daemon descarregará as compilações (veja Usando o recurso de descarregamento) ou simplesmente falhará.

--max-silent-time=segundos

Quando o processo de compilação ou substituição permanecer em silêncio por mais de segundos, encerra-o e relata uma falha de compilação.

The default value is 3600 (one hour).

O valor especificado aqui pode ser substituído pelos clientes (veja --max-silent-time).

--timeout=segundos

Da mesma forma, quando o processo de compilação ou substituição durar mais que segundos, encerra-o e relata uma falha de compilação.

O valor padrão é 24 horas.

O valor especificado aqui pode ser substituído pelos clientes (veja --timeout).

--rounds=N

Compila cada derivação n vezes seguidas e gera um erro se os resultados consecutivos da compilação não forem idênticos bit a bit. Observe que essa configuração pode ser substituída por clientes como guix build (veja Invocando guix build).

Quando usado em conjunto com --keep-failed, uma saída de comparação é mantida no armazém, sob /gnu/store/…-check. Isso facilita procurar por diferenças entre os dois resultados.

--debug

Produz uma saída de depuração.

Isso é útil para depurar problemas de inicialização do daemon, mas pode ser substituído pelos clientes, por exemplo, a opção --verbosity de guix build (veja Invocando guix build).

--chroot-directory=dir

adiciona dir ao chroot de compilação.

Isso pode alterar o resultado dos processos de compilação – por exemplo, se eles usam dependências opcionais encontradas em dir quando estão disponíveis, e não o contrário. Por esse motivo, não é recomendável fazê-lo. Em vez disso, verifique se cada derivação declara todas as entradas necessárias.

--disable-chroot

Desabilita compilações em chroot.

O uso dessa opção não é recomendado, pois, novamente, isso permitiria que os processos de compilação obtivessem acesso a dependências não declaradas. Porém, é necessário quando o guix-daemon está sendo executado em uma conta de usuário sem privilégios.

--log-compression=tipo

Compacta logs de compilação de aconrdo com tipo, que pode ser um entre gzip, bzip2 e none.

A menos que --lose-logs seja usado, todos os logs de build são mantidos em localstatedir. Para economizar espaço, o daemon os compacta automaticamente com gzip por padrão.

--discover[=yes|no]

Se deve descobrir servidores substitutos na rede local usando mDNS e DNS-SD.

Este recurso ainda é experimental. No entanto, aqui estão algumas considerações.

1. Pode ser mais rápido/menos caro do que buscar em servidores remotos;
2. Não há riscos de segurança, apenas substitutos genuínos serão usados (veja Autenticação de substituto);
3. Um invasor anunciando guix publish na sua LAN não pode fornecer binários maliciosos, mas pode descobrir qual software você está instalando;
4. Os servidores podem servir substitutos via HTTP, sem criptografia, para que qualquer pessoa na LAN possa ver qual software você está instalando.

Também é possível habilitar ou desabilitar a descoberta de servidor substituto em tempo de execução executando:

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication ¶

Desabilita “deduplicação” automática de arquivos no armazém.

Por padrão, os arquivos adicionados ao armazém são automaticamente “deduplicados”: se um arquivo recém-adicionado for idêntico a outro encontrado no armazém, o daemon tornará o novo arquivo um link físico para o outro arquivo. Isso pode reduzir notavelmente o uso do disco, às custas de um leve aumento na carga de entrada/saída no final de um processo de criação. Esta opção desativa essa otimização.

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

Diz se o coletor de lixo (GC) deve manter as saídas de derivações vivas.

Quando definido como yes, o GC manterá as saídas de qualquer derivação ativa disponível no armazém—os arquivos .drv. O padrão é no, o que significa que as saídas de derivação são mantidas somente se forem acessíveis a partir de uma raiz do GC. Veja Invocando guix gc, para mais informações sobre raízes do GC.

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

Diz se o coletor de lixo (GC) deve manter as derivações correspondentes às saídas vivas.

Quando definido como yes, como é o caso por padrão, o GC mantém derivações—ou seja, arquivos .drv—desde que pelo menos uma de suas saídas esteja ativa. Isso permite que os usuários acompanhem as origens dos itens em seu armazém. Defini-lo como no economiza um pouco de espaço em disco.

Dessa forma, definir --gc-keep-derivations como yes faz com que a vivacidade flua das saídas para as derivações, e definir --gc-keep-outputs como yes faz com que a vivacidade flua das derivações para as saídas. Quando ambos são definidos como yes, o efeito é manter todos os pré-requisitos de compilação (as fontes, o compilador, as bibliotecas e outras ferramentas de tempo de compilação) de objetos ativos no armazém, independentemente de esses pré-requisitos serem acessíveis a partir de uma raiz GC. Isso é conveniente para desenvolvedores, pois economiza reconstruções ou downloads.

--impersonate-linux-2.6

Em sistemas baseados em Linux, personifique o Linux 2.6. Isso significa que a chamada de sistema uname do kernel relatará 2.6 como o número da versão.

Isso pode ser útil para criar programas que (geralmente de forma errada) dependem do número da versão do kernel.

--lose-logs

Não mantenha logs de build. Por padrão, eles são mantidos em localstatedir/guix/log.

--system=sistema

Assuma sistema como o tipo de sistema atual. Por padrão, é o par arquitetura/kernel encontrado no momento da configuração, como x86_64-linux.

--listen=endpoint

Ouça conexões em endpoint. endpoint é interpretado como o nome do arquivo de um soquete de domínio Unix se ele começar com / (sinal de barra). Caso contrário, endpoint é interpretado como um nome de host ou nome de host e porta para ouvir. Aqui estão alguns exemplos:

--listen=/gnu/var/daemon

Ouça conexões no soquete de domínio Unix /gnu/var/daemon, criando-o se necessário.

--listen=localhost ¶

Ouça as conexões TCP na interface de rede correspondente a localhost, na porta 44146.

--listen=128.0.0.42:1234

Ouça as conexões TCP na interface de rede correspondente ao 128.0.0.42, na porta 1234.

Esta opção pode ser repetida várias vezes, nesse caso guix-daemon aceita conexões em todos os endpoints especificados. Os usuários podem informar aos comandos do cliente a qual endpoint se conectar definindo a variável de ambiente GUIX_DAEMON_SOCKET (veja GUIX_DAEMON_SOCKET).

Nota: O protocolo daemon é unauthenticated and unencrypted. Usar --listen=host é adequado em redes locais, como clusters, onde apenas nós confiáveis podem se conectar ao daemon de compilação. Em outros casos em que o acesso remoto ao daemon é necessário, recomendamos usar soquetes de domínio Unix junto com SSH.

Quando --listen é omitido, guix-daemon escuta conexões no soquete de domínio Unix localizado em localstatedir/guix/daemon-socket/socket.

2.4 Configuração de aplicativo

Ao usar Guix sobre uma distribuição GNU/Linux que não seja um Guix System — uma chamada distro alheia — algumas etapas adicionais são necessárias para colocar tudo no seu lugar. Aqui estão algumas delas.

• Localidades
• Name Service Switch
• Fontes X11
• Certificados X.509
• Pacotes Emacs

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-locales"))

guix install fontconfig
fc-cache -rv

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

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

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

2.5 Atualizando o Guix

Para atualizar o Guix, execute:

guix pull

Veja Invocando guix pull, para maiores informações.

Em uma distribuição estrangeira, você pode atualizar o daemon de compilação executando:

sudo -i guix pull

seguido por (supondo que sua distribuição use a ferramenta de gerenciamento de serviço systemd):

systemctl restart guix-daemon.service

No sistema Guix, a atualização do daemon é obtida reconfigurando o sistema (veja guix system reconfigure).

3.1 Limitações

Consideramos que o Guix System está pronto para uma ampla gama de casos de uso de "desktop” e servidores. As garantias de confiabilidade que ele fornece – atualizações e reversões transacionais, reprodutibilidade – tornam-no uma base sólida.

Cada vez mais serviços de sistema são fornecidos (veja Serviços).

No entanto, antes de prosseguir com a instalação, esteja ciente de que alguns serviços dos quais você depende ainda podem estar faltando na versão 4538aa4.

Mais do que um aviso de isenção de responsabilidade, este é um convite para relatar problemas (e histórias de sucesso!) e se juntar a nós para melhorá-los. Veja Contribuindo, para mais informações.

3.2 Considerações de Hardware

GNU Guix se concentra em respeitar a liberdade computacional do usuário. Ele é construído em torno do kernel Linux-libre, o que significa que apenas o hardware para o qual existem drivers e firmware de software livre é suportado. Hoje em dia, uma ampla gama de hardware disponível no mercado é suportada no GNU/Linux-libre – de teclados a placas gráficas, scanners e controladores Ethernet. Infelizmente, ainda existem áreas onde os fornecedores de hardware negam aos usuários o controle sobre sua própria computação, e tal hardware não é suportado no Guix System.

Uma das principais áreas onde faltam drivers ou firmware gratuitos são os dispositivos WiFi. Os dispositivos WiFi que funcionam incluem aqueles que usam chips Atheros (AR9271 e AR7010), que corresponde ao driver ath9k Linux-libre, e aqueles que usam chips Broadcom/AirForce (BCM43xx com Wireless-Core Revisão 5), que corresponde a o driver livre Linux b43-open. Existe firmware livre para ambos e está disponível imediatamente no Guix System, como parte do %base-firmware (veja firmware).

O instalador avisa você antecipadamente se detectar dispositivos que não funcionam devido à falta de firmware ou drivers gratuitos.

A Free Software Foundation administra Respects Your Freedom (RYF), um programa de certificação para produtos de hardware que respeitem sua liberdade e privacidade e garantam que você tenha controle sobre seu dispositivo. Recomendamos que você verifique a lista de dispositivos certificados RYF.

Outro recurso útil é o site H-Node. Ele contém um catálogo de dispositivos de hardware com informações sobre seu suporte no GNU/Linux.

3.3 Instalação em um pendrive e em DVD

Uma imagem de instalação ISO-9660 que pode ser gravada em um pendrive ou gravada em um DVD pode ser baixada em ‘https://ftp.gnu.org/gnu/guix/guix-system-install-4538aa4.x86_64-linux.iso’, onde você pode substituir x86_64-linux por um dos seguintes:

x86_64-linux

para um sistema GNU/Linux em CPUs de 64 bits compatíveis com Intel/AMD;

i686-linux

para um sistema GNU/Linux de 32 bits em CPUs compatíveis com Intel.

Certifique-se de baixar o arquivo .sig associado e verificar a autenticidade da imagem em relação a ele, seguindo estas linhas:

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

Se esse comando falhar porque você não possui a chave pública requerida, execute este comando para importá-lo:

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

e execute novamente o comando gpg --verify.

Observe que um aviso como "Esta chave não está certificada com uma assinatura confiável!” é normal.

Esta imagem contém as ferramentas necessárias para uma instalação. Ele deve ser copiado como está para um pendrive ou DVD grande o suficiente.

• Copiando para um pendrive
• Gravando em um DVD
• Inicializando

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

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

3.4 Preparando para instalação

Depois de inicializar, você pode usar o instalador gráfico guiado, o que facilita o início (veja Instalação gráfica guiada). Alternativamente, se você já está familiarizado com GNU/Linux e deseja mais controle do que o instalador gráfico oferece, você pode escolher o processo de instalação "manual” (veja Instalação manual).

O instalador gráfico está disponível em TTY1. Você pode obter shells root em TTYs 3 a 6 pressionando ctrl-alt-f3, ctrl-alt-f4, etc. TTY2 mostra esta documentação e você pode acessá-la com ctrl-alt -f2. A documentação pode ser navegada usando os comandos do leitor de informações (veja Stand-alone GNU Info). O sistema de instalação executa o daemon do mouse GPM, que permite selecionar texto com o botão esquerdo do mouse e colá-lo com o botão do meio.

Nota: A instalação requer acesso à Internet para que quaisquer dependências ausentes na configuração do sistema possam ser baixadas. Consulte a seção "Rede" abaixo.

3.5 Instalação gráfica guiada

O instalador gráfico é uma interface de usuário baseada em texto. Ele guiará você, com caixas de diálogo, pelas etapas necessárias para instalar o GNU Guix System.

As primeiras caixas de diálogo permitem que você configure o sistema conforme você o utiliza durante a instalação: você pode escolher o idioma, o layout do teclado e configurar a rede que será usada durante a instalação. A imagem abaixo mostra a caixa de diálogo de rede.

As etapas posteriores permitem particionar seu disco rígido, conforme mostrado na imagem abaixo, escolher se deseja ou não usar sistemas de arquivos criptografados, inserir o nome do host e a senha root e criar uma conta adicional, entre outras coisas.

Observe que, a qualquer momento, o instalador permite sair da etapa de instalação atual e retomar uma etapa anterior, conforme imagem abaixo.

Quando terminar, o instalador produz uma configuração do sistema operacional e a exibe (veja Usando o sistema de configuração). Nesse ponto você pode clicar em "OK” e a instalação continuará. Se tiver sucesso, você pode reiniciar no novo sistema e aproveitar. Veja Após a instalação do sistema, para saber o que vem a seguir!

3.6 Instalação manual

Esta seção descreve como você instalaria "manualmente” o GNU Guix System em sua máquina. Esta opção requer familiaridade com GNU/Linux, com o shell e com ferramentas de administração comuns. Se você acha que isso não é para você, considere usar o instalador gráfico guiado (veja Instalação gráfica guiada).

O sistema de instalação fornece shells root nos TTYs 3 a 6; pressione ctrl-alt-f3, ctrl-alt-f4 e assim por diante para alcançá-los. Inclui muitas ferramentas comuns necessárias para instalar o sistema, mas também é um sistema Guix completo. Isso significa que você pode instalar pacotes adicionais, caso precise, usando guix package (veja Invocando guix package).

• Layout de teclado, rede e particionamento
• Prosseguindo com a instalação

loadkeys dvorak

ifconfig -a

ip address

dhclient -v interface

ping -c 3 gnu.org

herd set-http-proxy guix-daemon URL

herd start ssh-daemon

cfdisk

parted /dev/sda set 1 esp on

mkfs.fat -F32 /dev/sda1

mkfs.ext4 -L my-root /dev/sda2

cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 my-partition
mkfs.ext4 -L my-root /dev/mapper/my-partition

mount LABEL=my-root /mnt

mkswap /dev/sda3
swapon /dev/sda3

# Este é 10 GiB de espaço de swap. Ajuste "count" para alterar o tamanho.
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
# Por segurança, torne o arquivo legível e gravável somente pelo root.
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

herd start cow-store /mnt

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

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

3.7 Após a instalação do sistema

Success, you’ve now booted into Guix System! Login to the system using the non-root user that you created during installation. You can upgrade the system whenever you want by running:

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

Isso cria uma nova geração sistema com os pacotes e serviços mais recentes.

Agora, veja Começando, junte-se a nós no #guix na rede IRC Libera.Chat ou no guix-devel@gnu.org para compartilhar sua experiência!

3.8 Instalando Guix em uma Máquina Virtual

Se você deseja instalar o Guix System em uma máquina virtual (VM) ou em um servidor virtual privado (VPS) em vez de na sua máquina favorita, esta seção é para você.

Para inicializar uma VM QEMU para instalar o Guix System em uma imagem de disco, siga estas etapas:

1. Primeiro, recupere e descompacte a imagem de instalação do sistema Guix conforme descrito anteriormente (veja Instalação em um pendrive e em DVD).
2. Crie uma imagem de disco que irá conter o sistema instalado. Para criar uma imagem de disco formatada em qcow2, use o comando qemu-img:

   qemu-img create -f qcow2 guix-system.img 50G
   

   O arquivo resultante será muito menor que 50 GB (normalmente menos de 1 MB), mas aumentará à medida que o dispositivo de armazenamento virtualizado for preenchido.

3. Boot the USB installation image in a VM:

   qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
     -nic user,model=virtio-net-pci -boot menu=on,order=d \
     -drive file=guix-system.img \
     -drive media=cdrom,readonly=on,file=guix-system-install-4538aa4.sistema.iso
   

   -enable-kvm é opcional, mas melhora significativamente o desempenho, veja Usando o Guix em uma Máquina Virtual.

4. Agora você está como root na VM, prossiga com o processo de instalação. Veja Preparando para instalação e siga as instruções.

Quando a instalação estiver concluída, você pode inicializar o sistema que está na sua imagem guix-system.img. Veja Usando o Guix em uma Máquina Virtual, para saber como fazer isso.

3.9 Compilando a imagem de instalação

A imagem de instalação descrita acima foi criada usando o comando guix system, especificamente:

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

Dê uma olhada em gnu/system/install.scm na árvore de origem e veja também Invoking guix system para mais informações sobre a imagem de instalação.

3.10 Construindo a imagem de instalação para placas ARM

Muitas placas ARM exigem uma variante específica do bootloader U-Boot.

Se você criar uma imagem de disco e o bootloader não estiver disponível de outra forma (em outra unidade de inicialização, etc.), é aconselhável criar uma imagem que inclua o bootloader, especificamente:

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

A20-OLinuXino-Lime2 é o nome do quadro. Se você especificar um quadro inválido, uma lista de quadros possíveis será mostrada.

5.1 Recursos

Aqui presumimos que você já deu os primeiros passos com o Guix (veja Começando) e gostaria de ter uma visão geral do que está acontecendo nos bastidores.

Ao usar o Guix, cada pacote acaba no armazém de pacotes, em seu próprio diretório — algo que lembra /gnu/store/xxx-package-1.2, onde xxx é uma string base32.

Em vez de se referir a esses diretórios, os usuários têm seu próprio perfil, que aponta para os pacotes que eles realmente querem usar. Esses perfis são armazenados dentro do diretório pessoal de cada usuário, em $HOME/.guix-profile.

Por exemplo, alice instala o GCC 4.7.2. Como resultado, /home/alice/.guix-profile/bin/gcc aponta para /gnu/store/…-gcc-4.7.2/bin/gcc. Agora, na mesma máquina, bob já tinha instalado o GCC 4.8.0. O perfil de bob simplesmente continua a apontar para /gnu/store/…-gcc-4.8.0/bin/gcc—ou seja, ambas as versões do GCC coexistem no mesmo sistema sem nenhuma interferência.

O comando guix package é a ferramenta central para gerenciar pacotes (veja Invocando guix package). Ele opera nos perfis por usuário e pode ser usado com privilégios normais de usuário.

O comando fornece as operações óbvias de instalação, remoção e atualização. Cada invocação é, na verdade, uma transação: ou a operação especificada é bem-sucedida ou nada acontece. Portanto, se o processo guix package for encerrado durante a transação, ou se ocorrer uma queda de energia durante a transação, o perfil do usuário permanecerá em seu estado anterior e continuará utilizável.

Além disso, qualquer transação de pacote pode ser revertida. Então, se, por exemplo, uma atualização instalar uma nova versão de um pacote que acabe tendo um bug sério, os usuários podem reverter para a instância anterior de seu perfil, que era conhecida por funcionar bem. Da mesma forma, a configuração global do sistema no Guix está sujeita a atualizações transacionais e roll-back (veja Começando).

Todos os pacotes no repositório de pacotes podem ser garbage-collected. O Guix pode determinar quais pacotes ainda são referenciados por perfis de usuário e remover aqueles que comprovadamente não são mais referenciados (veja Invocando guix gc). Os usuários também podem remover explicitamente gerações antigas de seus perfis para que os pacotes aos quais eles se referem possam ser coletados.

Guix adota uma abordagem puramente funcional para gerenciamento de pacotes, conforme descrito na introdução (veja Introdução). Cada nome de diretório de pacote /gnu/store contém um hash de todas as entradas que foram usadas para construir aquele pacote—compilador, bibliotecas, scripts de construção, etc. Essa correspondência direta permite que os usuários tenham certeza de que uma determinada instalação de pacote corresponde ao estado atual de sua distribuição. Também ajuda a maximizar a reprodutibilidade da construção: graças aos ambientes de construção isolados que são usados, uma determinada construção provavelmente produzirá arquivos de bits idênticos quando executada em máquinas diferentes (veja container).

Essa base permite que o Guix suporte transparent binary/source deployment. Quando um binário pré-construído para um item /gnu/store está disponível em uma fonte externa—um substituto, o Guix apenas o baixa e descompacta; caso contrário, ele constrói o pacote a partir da fonte, localmente (veja Substitutos). Como os resultados da construção são geralmente reproduzíveis bit a bit, os usuários não precisam confiar em servidores que fornecem substitutos: eles podem forçar uma construção local e desafiar os provedores (veja Invocando guix challenge).

O controle sobre o ambiente de construção é um recurso que também é útil para desenvolvedores. O comando guix shell permite que os desenvolvedores de um pacote configurem rapidamente o ambiente de desenvolvimento correto para seu pacote, sem ter que instalar manualmente as dependências do pacote em seu perfil (veja Invocando guix shell).

Todo o Guix e suas definições de pacote são controlados por versão, e guix pull permite que você "viaje no tempo” no histórico do próprio Guix (veja Invocando guix pull). Isso torna possível replicar uma instância do Guix em uma máquina diferente ou em um ponto posterior no tempo, o que por sua vez permite que você replique ambientes de software completos, enquanto retém o rastreamento de procedência preciso do software.

5.2 Invocando guix package

O comando guix package é a ferramenta que permite aos usuários instalar, atualizar e remover pacotes, bem como reverter para configurações anteriores. Essas operações funcionam no perfil de um usuário—um diretório de pacotes instalados. Cada usuário tem um perfil padrão em $HOME/.guix-profile. O comando opera apenas no próprio perfil do usuário e funciona com privilégios de usuário normais (veja Recursos). Sua sintaxe é:

guix package opções

Principalmente, opções especifica as operações a serem executadas durante a transação. Após a conclusão, um novo perfil é criado, mas as gerações anteriores do perfil permanecem disponíveis, caso o usuário queira reverter.

Por exemplo, para remover lua e instalar guile e guile-cairo em uma única transação:

guix package -r lua -i guile guile-cairo

Para sua conveniência, também fornecemos os seguintes aliases:

• guix search é um alias para guix package -s,
• guix install é um alias para guix package -i,
• guix remove é um alias para guix package -r,
• guix upgrade é um alias para guix package -u,
• e guix show é um alias para guix package --show=.

Esses aliases são menos expressivos que guix package e oferecem menos opções, então em alguns casos você provavelmente desejará usar guix package diretamente.

guix package também suporta uma abordagem declarativa em que o usuário especifica o conjunto exato de pacotes que estarão disponíveis e passa a ele via a opção --manifest (veja --manifest).

Para cada usuário, uma ligação simbólica para o perfil padrão do usuário é criado automaticamente em $HOME/.guix-profile. Esta ligação simbólico sempre aponta para a geração atual do perfil padrão do usuário. Assim, os usuários podem adicionar $HOME/.guix-profile/bin à sua variável de ambiente PATH e assim por diante. Se você não estiver usando o sistema Guix, considere adicionar as seguintes linhas ao seu ~/.bash_profile (veja Bash Startup Files em Manual de referência do GNU Bash) para que os shells recém-gerados obtenham todos as definições corretas de variáveis de ambiente:

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

Em uma configuração multiusuário, os perfis de usuário são armazenados em um local registrado como raiz do coletor de lixo, para o qual $HOME/.guix-profile aponta (veja Invocando guix gc). Esse diretório geralmente é localstatedir/guix/profiles/per-user/usuário, onde localstatedir é o valor passado para configure como -- localstatedir e usuário é o nome do usuário. O diretório per-user é criado quando guix-daemon é iniciado, e o subdiretório usuário é criado por guix package.

As seguintes opções podem ser usadas:

--install=pacote …

-i pacote …

Instale os pacotes especificados.

Cada pacote pode especificar um nome de pacote simples como guile, opcionalmente seguido por uma arroba e número de versão, como guile@3.0.7 ou simplesmente guile@3.0. Neste último caso, a versão mais recente prefixada por 3.0 é selecionada.

Se nenhum número de versão for especificado, a versão mais recente disponível será selecionada. Além disso, tal especificação pacote pode conter dois pontos, seguido pelo nome de uma das saídas do pacote, como em gcc:doc ou binutils@2.22:lib (veja Pacotes com múltiplas saídas).

Pacotes com um nome correspondente (e opcionalmente versão) são procurados entre os módulos de distribuição GNU (veja Módulos de pacote).

Alternativamente, um pacote pode especificar diretamente um nome de arquivo de armazém como /gnu/store/...-guile-3.0.7, conforme produzido por, por exemplo, guix build.

Às vezes, os pacotes têm propagated-inputs: são dependências que são instaladas automaticamente junto com o pacote necessário (veja propagated-inputs em package objetos, para obter informações sobre entradas propagadas em definições de pacote).

Um exemplo é a biblioteca GNU MPC: seus arquivos de cabeçalho C referem-se aos da biblioteca GNU MPFR, que por sua vez se refere aos da biblioteca GMP. Assim, ao instalar o MPC, as bibliotecas MPFR e GMP também são instaladas no perfil; a remoção do MPC também remove o MPFR e o GMP — a menos que eles também tenham sido explicitamente instalados pelo usuário.

Além disso, os pacotes às vezes dependem da definição de variáveis de ambiente para seus caminhos de pesquisa (veja a explicação de --search-paths abaixo). Quaisquer definições de variáveis ambientais ausentes ou possivelmente incorretas são relatadas aqui.

--install-from-expression=exp

-e exp

Instale o pacote avaliado por exp.

exp deve ser uma expressão de Scheme avaliada como um objeto <package>. Esta opção é particularmente útil para desambiguar variantes de um pacote com o mesmo nome, com expressões como (@(gnu packages commencement) guile-final).

Observe que esta opção instala a primeira saída do pacote especificado, o que pode ser insuficiente quando for necessária uma saída específica de um pacote de múltiplas saídas.

--install-from-file=arquivo

-f arquivo

Instale o pacote avaliado pelo código em arquivo.

Por exemplo, arquivo pode conter uma definição como esta (veja Definindo pacotes):

(use-modules (guix)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (build-system gnu-build-system)
  (synopsis "Hello, GNU world: An example GNU package")
  (description "Guess what GNU Hello prints!")
  (home-page "http://www.gnu.org/software/hello/")
  (license gpl3+))

Os desenvolvedores podem achar útil incluir um arquivo guix.scm na raiz da árvore de origem do projeto que pode ser usado para testar instantâneos de desenvolvimento e criar ambientes de desenvolvimento reproduzíveis (veja Invocando guix shell).

O arquivo também pode conter uma representação JSON de uma ou mais definições de pacote. Executar guix package -f em hello.json com o seguinte conteúdo resultaria na instalação do pacote greeter após construir myhello:

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

--remove=pacote …

-r pacote …

Remova os pacotes especificados.

Quanto a --install, cada pacote pode especificar um número de versão e/ou nome de saída além do nome do pacote. Por exemplo, ‘-r glibc:debug’ removeria a saída de glibc.

--upgrade[=regexp …] ¶

-u [regexp …]

Atualize todos os pacotes instalados. Se um ou mais regexps forem especificados, atualize apenas os pacotes instalados cujo nome corresponda a um regexp. Veja também a opção --do-not-upgrade abaixo.

Note que isso atualiza o pacote para a versão mais recente dos pacotes encontrados na distribuição atualmente instalada. Para atualizar sua distribuição, você deve executar regularmente guix pull (veja Invocando guix pull).

Ao atualizar, as transformações de pacote que foram aplicadas originalmente ao criar o perfil são automaticamente reaplicadas (veja Opções de transformação de pacote). Por exemplo, suponha que você instalou o Emacs pela ponta do seu branch de desenvolvimento com:

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

Na próxima vez que você executar guix upgrade, o Guix puxará novamente a ponta do branch de desenvolvimento do Emacs e compilará emacs-next a partir desse checkout.

Observe que opções de transformação como --with-branch e --with-source dependem do estado externo; cabe a você garantir que elas funcionem conforme o esperado. Você também pode descartar transformações que se aplicam a um pacote executando:

guix install pacote

--do-not-upgrade[=regexp …]

Quando usado junto com a opção --upgrade, não atualize nenhum pacote cujo nome corresponda a um regexp. Por exemplo, para atualizar todos os pacotes no perfil atual, exceto aqueles que contêm a substring "emacs”:

$ guix package --upgrade . --do-not-upgrade emacs

--manifest=arquivo ¶

-m arquivo

Crie uma nova geração do perfil a partir do objeto manifest retornado pelo código Scheme em arquivo. Esta opção pode ser repetida várias vezes, em cujo caso os manifestos são concatenados.

Isso permite que você declarando o conteúdo do perfil em vez de construí-lo por meio de uma sequência de --install e comandos similares. A vantagem é que arquivo pode ser colocado sob controle de versão, copiado para máquinas diferentes para reproduzir o mesmo perfil, e assim por diante.

arquivo deve retornar um objeto manifest, que é aproximadamente uma lista de pacotes:

(use-package-modules guile emacs)

(packages->manifest
 (list emacs
       guile-2.0
       ;; Usa uma saída de pacote específica.
       (list guile-2.0 "debug")))

Veja Escrevendo manifestos, para obter informações sobre como escrever um manifesto. Veja --export-manifest, para aprender como obter um arquivo de manifesto de um perfil existente.

--roll-back ¶

Reverta para a geração anterior do perfil, ou seja, desfaça a última transação.

Quando combinado com opções como --install, a reversão ocorre antes de qualquer outra ação.

Ao reverter da primeira geração que realmente contém pacotes instalados, o perfil é feito para apontar para a geração zero, que não contém arquivos além de seus próprios metadados.

Após ter revertido, instalar, remover ou atualizar pacotes sobrescreve gerações futuras anteriores. Assim, o histórico das gerações em um perfil é sempre linear.

--switch-generation=padrão ¶

-S padrão

Mude para uma geração específica definida por padrão.

padrão pode ser um número de geração ou um número prefixado com "+” ou "-”. O último significa: mover para frente/para trás por um número especificado de gerações. Por exemplo, se você quiser retornar para a última geração após --roll-back, use --switch-generation=+1.

A diferença entre --roll-back e --switch-generation=-1 é que --switch-generation não fará uma geração zero, então se uma geração especificada não existir, a geração atual não será alterada.

--search-paths[=tipo] ¶

Relata definições de variáveis de ambiente, na sintaxe Bash, que podem ser necessárias para usar o conjunto de pacotes instalados. Essas variáveis de ambiente são usadas para especificar caminhos de busca para arquivos usados por alguns dos pacotes instalados.

Por exemplo, o GCC precisa que as variáveis de ambiente CPATH e LIBRARY_PATH sejam definidas para que ele possa procurar cabeçalhos e bibliotecas no perfil do usuário (veja Environment Variables em Usando o GNU Compiler Collection (GCC)). Se o GCC e, digamos, a biblioteca C estiverem instalados no perfil, então --search-paths sugerirá definir essas variáveis como perfil/include e perfil/lib, respectivamente (veja Caminhos de pesquisa, para obter informações sobre especificações de caminho de pesquisa associadas a pacotes.)

O caso de uso típico é definir essas variáveis de ambiente no shell:

$ eval $(guix package --search-paths)

tipo pode ser um dos seguintes: exact, prefix ou suffix, o que significa que as definições de variáveis de ambiente retornadas serão configurações exatas ou prefixos ou sufixos do valor atual dessas variáveis. Quando omitido, tipo assume como padrão exact.

Esta opção também pode ser usada para calcular os caminhos de busca combinados de vários perfis. Considere este exemplo:

$ guix package -p foo -i guile
$ guix package -p bar -i guile-json
$ guix package -p foo -p bar --search-paths

O último comando acima relata sobre a variável GUILE_LOAD_PATH, embora, considerados individualmente, nem foo nem bar levariam a essa recomendação.

--profile=perfil

-p perfil

Use perfil em vez do perfil padrão do usuário.

perfil deve ser o nome de um arquivo que será criado após a conclusão. Concretamente, perfil será uma mera ligação simbólica ("symlink”) apontanda para o perfil real onde os pacotes estão instalados:

$ guix install hello -p ~/code/my-profile
…
$ ~/code/my-profile/bin/hello
Olá, mundo!

Tudo o que é preciso para se livrar do perfil é remover este link simbólico e seus irmãos que apontam para gerações específicas:

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

--list-profiles

Liste todos os perfis dos usuários:

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

Ao executar como root, liste todos os perfis de todos os usuários.

--allow-collisions

Permitir pacotes de colisão no novo perfil. Use por sua conta e risco!

Por padrão, guix package relata como um erro collisions no perfil. Colisões acontecem quando duas ou mais versões ou variantes diferentes de um determinado pacote acabam no perfil.

--bootstrap

Use o bootstrap Guile para construir o perfil. Esta opção é útil somente para desenvolvedores de distribuição.

Além dessas ações, guix package suporta as seguintes opções para consultar o estado atual de um perfil ou a disponibilidade de pacotes:

--search=regexp

-s regexp

Liste os pacotes disponíveis cujo nome, sinopse ou descrição correspondem a regexp (sem distinção entre maiúsculas e minúsculas), classificados por relevância. Imprima todos os metadados dos pacotes correspondentes no formato recutils (veja bancos de dados GNU recutils em manual GNU recutils).

Isso permite que campos específicos sejam extraídos usando o comando recsel, por exemplo:

$ guix package -s malloc | recsel -p name,version,relevance
name: jemalloc
version: 4.5.0
relevance: 6

name: glibc
version: 2.25
relevance: 1

name: libgc
version: 7.6.0
relevance: 1

Da mesma forma, para mostrar o nome de todos os pacotes disponíveis sob os termos da GNU LGPL versão 3:

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

name: gmp
…

Também é possível refinar os resultados da pesquisa usando vários sinalizadores -s para guix package, ou vários argumentos para guix search. Por exemplo, o comando a seguir retorna uma lista de jogos de tabuleiro (desta vez usando o alias guix search):

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

Se omitissemos -s game, também teríamos pacotes de software que lidam com placas de circuito impresso; remover os colchetes angulares em torno de board adicionaria ainda mais pacotes relacionados a teclados.

E agora um exemplo mais elaborado. O comando a seguir procura bibliotecas criptográficas, filtra as bibliotecas Haskell, Perl, Python e Ruby e imprime o nome e a sinopse dos pacotes correspondentes:

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

Veja Selection Expressions em manual GNU recutils, para obter mais informações sobre expressões de seleção para recsel -e.

--show=pacote

Exibe detalhes sobre pacote, retirados da lista de pacotes disponíveis, no formato recutils (veja GNU Recutils Databases em GNU Recutils Manual).

$ guix package --show=guile | recsel -p name,version
name: guile
version: 3.0.5

name: guile
version: 3.0.2

name: guile
version: 2.2.7
…

Você também pode especificar o nome completo de um pacote para obter detalhes apenas sobre uma versão específica dele (desta vez usando o alias guix show):

$ guix show guile@3.0.5 | recsel -p name,version
name: guile
version: 3.0.5

--list-installed[=regexp]

-I [regexp]

Lista os pacotes instalados mais recentemente no perfil especificado, com os pacotes instalados mais recentemente mostrados por último. Quando regexp for especificado, liste apenas os pacotes instalados cujo nome corresponda a regexp.

Para cada pacote instalado, imprima os seguintes itens, separados por tabulações: o nome do pacote, sua string de versão e a parte do pacote que está instalada (por exemplo, out para a saída predefinida, include para os seus cabeçalhos, etc.) e o caminho deste pacote no armazém.

--list-available[=regexp]

-A [regexp]

Lista de pacotes atualmente disponíveis na distribuição para este sistema (veja Distribuição GNU). Quando regexp for especificado, liste apenas os pacotes disponíveis cujo nome corresponda a regexp.

Para cada pacote, imprima os seguintes itens separados por tabulações: seu nome, sua string de versão, as partes do pacote (veja Pacotes com múltiplas saídas) e o local de origem de sua definição.

--list-generations[=padrão] ¶

-l [padrão]

Retorne uma lista de gerações junto com suas datas de criação; para cada geração, exiba os pacotes instalados, com os pacotes instalados mais recentemente mostrados por último. Observe que a geração zero nunca é mostrada.

Para cada pacote instalado, mostre os seguintes itens, separados por tabulações: o nome de um pacote, sua string de versão, a parte do pacote que está instalada (veja Pacotes com múltiplas saídas) e a localização deste pacote em o armazém.

Quando padrão é usado, o comando retorna apenas gerações correspondentes. Os padrões válidos incluem:

• Inteiros e números inteiros separados por vírgula. Ambos os padrões denotam números de geração. Por exemplo, --list-generations=1 retorna o primeiro.

  E --list-generations=1,8,2 gera três gerações na ordem especificada. Não são permitidos espaços nem vírgulas finais.

• Intervalos. --list-generations=2..9 mostra o gerações especificadas e tudo mais. Observe que o início de um intervalo deve ser menor que o seu final.

  Também é possível omitir o ponto final. Por exemplo, --list-generations=2.. retorna todas as gerações começando pela segunda.

• Duração. Você também pode visitar os últimos N dias, semanas, ou meses passando um número inteiro junto com a primeira letra da duração. Por exemplo, --list-generations=20d lista gerações com até 20 dias.

--delete-generations[=padrão]

-d [padrão]

Quando padrão for omitido, exclua todas as gerações, exceto a atual.

Este comando aceita os mesmos padrões de --list-Generations. Quando pattern for especificado, exclua as gerações correspondentes. Quando padrão especifica uma duração, as gerações mais antigas que a duração especificada correspondem. Por exemplo, --delete-generations=1m exclui gerações com mais de um mês.

Se a geração atual corresponder, ela será não excluída. Além disso, a geração zero nunca é excluída.

Observe que a exclusão de gerações impede a reversão para elas. Conseqüentemente, este comando deve ser usado com cuidado.

--export-manifest

Escreva na saída padrão um manifesto adequado para --manifest correspondente ao(s) perfil(s) selecionado(s).

Esta opção destina-se a ajudá-lo a migrar do modo operacional "imperativo” — executando guix install, guix upgrade, etc.—para o modo declarativo que --manifest ofertas.

Observe que o manifesto resultante aproxima o que seu perfil realmente contém; por exemplo, dependendo de como seu perfil foi criado, ele pode se referir a pacotes ou versões de pacotes que não são exatamente o que você especificou.

Tenha em mente que um manifesto é puramente simbólico: ele contém apenas nomes de pacotes e possivelmente versões, e seu significado varia com o tempo. Se você quiser “fixar” canais nas revisões que foram usadas para construir o(s) perfil(es), veja --export-channels abaixo.

--export-channels

Escreva na saída padrão a lista de canais usados pelo(s) perfil(s) selecionado(s), em um formato adequado para guix pull --channels ou guix time-machine --channels (veja Canais) . .

Juntamente com --export-manifest, esta opção fornece informações que permitem replicar o perfil atual (veja Replicando Guix).

No entanto, observe que a saída deste comando aproxima o que foi realmente usado para construir este perfil. Em particular, um único perfil pode ter sido construído a partir de diversas revisões diferentes do mesmo canal. Nesse caso, --export-manifest escolhe a última e escreve a lista de outras revisões em um comentário. Se você realmente precisa escolher pacotes de análises de canais diferentes, você pode usar inferiores em seu manifesto para fazer isso (veja Inferiores).

Juntamente com --export-manifest, este é um bom ponto de partida se você estiver disposto a migrar do modelo "imperativo" para o modelo totalmente declarativo que consiste em um arquivo de manifesto junto com um arquivo de canais fixando o canal exato revisão(ões) que você deseja.

Finalmente, como guix package pode realmente iniciar processos de construção, ele suporta todas as opções de construção comuns (veja Opções de compilação comuns). Ele também oferece suporte a opções de transformação de pacotes, como --with-source, e as preserva em atualizações (veja Opções de transformação de pacote).

5.3 Substitutos

Guix suporta implantação transparente de origem/binário, o que significa que ele pode construir coisas localmente ou baixar itens pré-construídos de um servidor, ou ambos. Chamamos esses itens pré-construídos de substitutos—eles são substitutos para resultados de construção local. Em muitos casos, baixar um substituto é muito mais rápido do que construir coisas localmente.

Substitutos podem ser qualquer coisa resultante de uma construção de derivação (veja Derivações). Claro, no caso comum, eles são binários de pacotes pré-construídos, mas tarballs de origem, por exemplo, que também resultam de construções de derivação, podem estar disponíveis como substitutos.

• Official Substitute Servers
• Autorização de servidor substituto
• Obtendo substitutos de outros servidores
• Autenticação de substituto
• Configurações de proxy
• Falha na substituição
• Confiança em binários

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

$ guix build emacs --dry-run
A seguinte derivações seriam compiladas:
   /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
   /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
   /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
   /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
…

$ guix build emacs --dry-run
112.3 MB seriam baixados:
   /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
   /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
   /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
   /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
…

(operating-system
 ;; …
 (services
  ;; Suponha que estamos começando com '%desktop-services'. Substitua-o
  ;; pela lista de serviços que você está realmente usando.
  (modify-services %desktop-services
    (guix-service-type config =>
                       (guix-configuration
                        (inherit config)
                        (substitute-urls
                         (append (list "https://guix.example.org")
                                 %default-substitute-urls))
                        (authorized-keys
                         (append (list (local-file "./key.pub"))
                                 %default-authorized-guix-keys)))))))

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

--substitute-urls="https://a.example.org https://b.example.org"

5.4 Pacotes com múltiplas saídas

Frequentemente, os pacotes definidos no Guix têm uma única saída — ou seja, o pacote fonte leva a exatamente um diretório no armazém. Ao executar guix install glibc, instala-se a saída padrão do pacote GNU libc; A saída padrão é chamada out, mas seu nome pode ser omitido conforme mostrado neste comando. Neste caso específico, a saída padrão de glibc contém todos os arquivos de cabeçalho C, bibliotecas compartilhadas, bibliotecas estáticas, documentação de informações e outros arquivos de suporte.

Às vezes é mais apropriado separar os vários tipos de arquivos produzidos a partir de um único pacote fonte em saídas separadas. Por exemplo, a biblioteca GLib C (usada pelo GTK+ e pacotes relacionados) instala mais de 20 MiB de documentação de referência como páginas HTML. Para economizar espaço para usuários que não precisam, a documentação vai para uma saída separada, chamada doc. Para instalar a saída principal do GLib, que contém tudo menos a documentação, seria executado:

guix install glib

O comando para instalar sua documentação é:

guix install glib:doc

Embora a sintaxe de dois pontos funcione para especificação de linha de comando de saídas de pacotes, ela não funcionará ao usar uma variável de pacote no código do Scheme. Por exemplo, para adicionar a documentação do glib aos pacotes instalados globalmente de um operating-system (veja operating-system Reference), uma lista de dois itens, sendo o primeiro a variável de pacote e o segundo o nome da saída a ser selecionada (uma string), devem ser usados:

(use-modules (gnu packages glib))
;; glib-with-documentation é o símbolo de Guile para o pacote glib
(operating-system
 ...
 (packages
  (append
   (list (list glib-with-documentation "doc"))
         %base-packages)))

Alguns pacotes instalam programas com diferentes "pegadas de dependência”. Por exemplo, o pacote WordNet instala ferramentas de linha de comando e interfaces gráficas de usuário (GUIs). Os primeiros dependem exclusivamente da biblioteca C, enquanto os últimos dependem apenas do Tcl/Tk e das bibliotecas X subjacentes. Nesse caso, deixamos as ferramentas de linha de comando na saída padrão, enquanto as GUIs ficam em uma saída separada. Isso permite que usuários que não precisam de GUIs economizem espaço. O comando guix size pode ajudar a descobrir tais situações (veja Invocando guix size). guix graph também pode ser útil (veja Invocando guix graph).

Existem vários desses pacotes de múltiplas saídas na distribuição GNU. Outros nomes de saída convencionais incluem lib para bibliotecas e possivelmente arquivos de cabeçalho, bin para programas independentes e debug para informações de depuração (veja Instalando arquivos de depuração). A saída de um pacote está listada na terceira coluna da saída de guix package --list-available (veja Invocando guix package).

5.5 Invocando guix locate

Há tantos softwares gratuitos por aí que, mais cedo ou mais tarde, você precisará procurar por pacotes. O comando guix search que vimos antes (veja Invocando guix package) permite pesquisar por palavras-chave:

guix search video editor

Às vezes, você deseja descobrir qual pacote fornece um determinado arquivo, e é aí que entra guix locate. Veja como você pode encontrar o comando ls:

$ guix locate ls
coreutils@9.1       /gnu/store/…-coreutils-9.1/bin/ls

É claro que o comando funciona para qualquer arquivo, não apenas para comandos:

$ guix locate unistr.h
icu4c@71.1          /gnu/store/…/include/unicode/unistr.h
libunistring@1.0    /gnu/store/…/include/unistr.h

Você também pode especificar padrões de globo com curingas. Por exemplo, aqui está como você procuraria pacotes que fornecem arquivos .service:

$ guix locate -g '*.service'
man-db@2.11.1        …/lib/systemd/system/man-db.service
wpa-supplicant@2.10  …/system-services/fi.w1.wpa_supplicant1.service

O comando guix locate depende de um banco de dados que mapeia nomes de arquivos para nomes de pacotes. Por padrão, ele cria automaticamente esse banco de dados, caso ele ainda não exista, percorrendo os pacotes disponíveis localmente, o que pode levar alguns minutos (dependendo do tamanho do seu armazém e da velocidade do seu dispositivo de armazenamento).

Nota: Por enquanto, guix locate constrói seu banco de dados baseado em conhecimento puramente local – o que significa que você não encontrará pacotes que nunca chegaram ao sue armazém. Eventualmente, ele suportará o download de um banco de dados pré-construído para que você possa encontrar mais pacotes.

Por padrão, guix locate primeiro tenta procurar um banco de dados de todo o sistema, geralmente em /var/cache/guix/locate; Se não existir ou for muito antigo, ele retornará ao banco de dados por usuário, por padrão em ~/.cache/guix/locate. Em um sistema multiusuário, os administradores podem querer atualizar periodicamente o banco de dados de todo o sistema para que todos os usuários possam se beneficiar dele, por exemplo, configurando package-database-service-type (veja package-database-service-type).

A sintaxe geral é:

guix locate [opções…] arquivo…

... onde arquivo é o nome de um arquivo a ser pesquisado (especificamente, o "nome base" do arquivo: arquivos cujos diretórios pais são chamados arquivo não são correspondidos).

As opções disponíveis são as seguintes:

--glob

-g

Interprete arquivo… como padrões de globo—padrões que podem incluir caracteres curinga, como ‘*.scm’ para denotar todos os arquivos que terminam em ‘.scm’.

--stats

Exibir estatísticas do banco de dados.

--update

-u

Atualize o banco de dados dos arquivos.

Por padrão, o banco de dados é atualizado automaticamente quando é muito antigo.

--clear

Limpe o banco de dados e preencha-o novamente.

Esta opção permite começar de novo, garantindo que os dados antigos sejam removidos do banco de dados, o que também evita ter um banco de dados em constante crescimento. Por padrão, guix locate faz isso automaticamente periodicamente, embora com pouca frequência.

--database=arquivo

Use arquivo como banco de dados, criando-o se necessário.

Por padrão, guix locate escolhe o banco de dados em ~/.cache/guix ou /var/cache/guix, o que for mais recente.

--method=método

-m método

Use método para selecionar o conjunto de pacotes a serem indexados. Os valores possíveis são:

manifests

Este é o método padrão: ele funciona percorrendo perfis na máquina e gravando os pacotes que encontra – pacotes instalados por você ou por outros usuários da máquina, direta ou indiretamente. É rápido mas você pode perder outros pacotes disponíveis no armazém mas não referenciados por nenhum perfil.

store

Este é um método mais lento, porém mais exaustivo: verifica entre todos os pacotes existentes aqueles que estão disponíveis no armazém e os registra.

5.6 Invocando guix gc

Pacotes instalados mas não usados podem ser garbage-collected. O comando guix gc permite que os usuários executem explicitamente o coletor de lixo para recuperar espaço do diretório /gnu/store. É a maneira única de remover arquivos de /gnu/store — remover arquivos ou diretórios manualmente pode quebrá-los sem possibilidade de reparo!

O coletor de lixo possui um conjunto de raizes conhecidos: qualquer arquivo em /gnu/store acessível a partir de uma raiz é considerado live e não pode ser excluído; Qualquer outro arquivo é considerado dead e pode ser excluído. O conjunto de raízes do coletor de lixo (abreviadamente “Raízes GC”) inclui perfis de usuário padrão; por padrão, as ligações simbólicas em /var/guix/gcroots representam essas raízes do GC. Novas raízes de GC podem ser adicionadas com guix build --root, por exemplo (veja Invocando guix build). O comando guix gc --list-roots os lista.

Antes de executar guix gc --collect-garbage para liberar espaço, geralmente é útil remover gerações antigas dos perfis de usuário; dessa forma, compilações de pacotes antigos referenciadas por essas gerações podem ser recuperadas. Isso é conseguido executando guix package --delete-generations (veja Invocando guix package).

Nossa recomendação é executar uma coleta de lixo periodicamente ou quando houver pouco espaço em disco. Por exemplo, para garantir que pelo menos 5 GB estejam disponíveis no disco, basta executar:

guix gc -F 5G

É perfeitamente seguro executar como um trabalho periódico não interativo (veja Execução de trabalho agendado, para saber como configurar tal trabalho). Executar guix gc sem argumentos coletará o máximo de lixo possível, mas isso geralmente é inconveniente: você pode ter que reconstruir ou baixar novamente um software que está "morto" do ponto de vista do GC, mas que é necessário para construir outras peças de software - por exemplo, a cadeia de ferramentas do compilador.

O comando guix gc tem três modos de operação: pode ser usado para coletar o lixo de quaisquer arquivos mortos (o padrão), para excluir arquivos específicos (a opção --delete), para imprimir lixo- informações do coletor ou para consultas mais avançadas. As opções de coleta de lixo são as seguintes:

--collect-garbage[=min]

-C [min]

Colete lixo, ou seja, arquivos e subdiretórios /gnu/store inacessíveis. Esta é a operação padrão quando nenhuma opção é especificada.

Quando min for fornecido, pare quando min bytes forem coletados. min pode ser um número de bytes ou pode incluir uma unidade como sufixo, como MiB para mebibytes e GB para gigabytes (veja especificações de tamanho em GNU Coreutils).

Quando min for omitido, colete todo o lixo.

--free-space=free

-F free

Colete o lixo até que o espaço free esteja disponível em /gnu/store, se possível; free denota espaço de armazenamento, como 500MiB, conforme descrito acima.

Quando free ou mais já estiver disponível em /gnu/store, não faça nada e saia imediatamente.

--delete-generations[=duração]

-d [duração]

Antes de iniciar o processo de coleta de lixo, exclua todas as gerações anteriores a duração, para todos os perfis de usuário e gerações do ambiente pessoal. Quando executado como root, isso se aplica a todos os perfis de todos os usuários.

Por exemplo, este comando exclui todas as gerações de todos os seus perfis com mais de 2 meses (exceto as gerações atuais) e depois libera espaço até que pelo menos 10 GiB estejam disponíveis:

guix gc -d 2m -F 10G

--delete

-D

Tentativa de excluir todos os arquivos e diretórios de armazém especificados como argumentos. Isso falhará se alguns dos arquivos não estiverem no armazém ou se ainda estiverem ativos.

--list-failures

Listar itens de armazém correspondentes a falhas de compilação em cache.

Isso não imprime nada, a menos que o daemon tenha sido iniciado com --cache-failures (veja --cache-failures).

--list-roots

Listar as raízes do GC de propriedade do usuário; quando executado como root, listar todas as raízes do GC.

--list-busy

Listar itens de armazém em uso por processos em execução no momento. Esses itens de armazém são efetivamente considerados raízes GC: eles não podem ser excluídos.

--clear-failures

Remova os itens de armazém especificados do cache de compilação com falha.

Novamente, essa opção só faz sentido quando o daemon é iniciado com --cache-failures. Caso contrário, não faz nada.

--list-dead

Exibe a lista de arquivos e diretórios mortos ainda presentes no armazém, ou seja, arquivos e diretórios que não podem mais ser acessados de nenhuma raiz.

--list-live

Exibe a lista de arquivos e diretórios do armazém ativa.

Além disso, as referências entre arquivos de armazém existentes podem ser consultadas:

--references ¶

--referrers

Listar as referências (respectivamente, os referenciadores) dos arquivos de armazém fornecidos como argumentos.

--requisites ¶

-R

Liste os requisitos dos arquivos de armazém passados como argumentos. Os requisitos incluem os próprios arquivos de armazém, suas referências e as referências destes, recursivamente. Em outras palavras, a lista retornada é o fechamento transitivo dos arquivos de armazém.

Veja Invocando guix size, para uma ferramenta para criar o perfil do tamanho do fechamento de um elemento. Veja Invocando guix graph, para uma ferramenta para visualizar o grafo de referências.

--derivers ¶

Retorna a(s) derivação(ões) que levam aos itens de armazém fornecidos (veja Derivações).

Por exemplo, este comando:

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

retorna o(s) arquivo(s) .drv que levam ao pacote emacs instalado no seu perfil.

Note que pode haver zero arquivos .drv correspondentes, por exemplo porque esses arquivos foram coletados como lixo. Também pode haver mais de um .drv correspondente devido a derivações de saída fixa.

Por fim, as seguintes opções permitem que você verifique a integridade do armazém e controle o uso do disco.

--verify[=opções] ¶

Verifique a integridade do armazém.

Por padrão, certifique-se de que todos os itens de armazém marcados como válidos no banco de dados do daemon realmente existam em /gnu/store.

Quando fornecido, opções deve ser uma lista separada por vírgulas contendo um ou mais de contents e repair.

Ao passar --verify=contents, o daemon calcula o hash de conteúdo de cada item do armazém e o compara com seu hash no banco de dados. Incompatibilidades de hash são relatadas como corrupções de dados. Como ele percorre todos os arquivos no armazém, esse comando pode levar muito tempo, especialmente em sistemas com uma unidade de disco lenta.

Usar --verify=repair ou --verify=contents,repair faz com que o daemon tente reparar itens corrompidos do armazém buscando substitutos para eles (veja Substitutos). Como o reparo não é atômico e, portanto, potencialmente perigoso, ele está disponível apenas para o administrador do sistema. Uma alternativa leve, quando você sabe exatamente quais itens no armazém estão corrompidos, é guix build --repair (veja Invocando guix build).

--optimize ¶

Otimize o armazém vinculando fisicamente arquivos idênticos — isso é deduplication.

O daemon executa a desduplicação após cada importação bem-sucedida de build ou archive, a menos que tenha sido iniciado com --disable-deduplication (veja --disable-deduplication). Portanto, essa opção é útil principalmente quando o daemon estava em execução com --disable-deduplication.

--vacuum-database ¶

Guix usa um banco de dados sqlite para manter o controle dos itens no armazém (veja O armazém). Com o tempo, é possível que o banco de dados cresça muito e se torne fragmentado. Como resultado, pode-se desejar limpar o espaço liberado e juntar as páginas parcialmente usadas no banco de dados deixadas para trás por pacotes removidos ou após executar o coletor de lixo. Executar sudo guix gc --vacuum-database bloqueará o banco de dados e VACUUM o store, desfragmentando o banco de dados e expurgando as páginas liberadas, desbloqueando o banco de dados quando terminar.

5.7 Invocando guix pull

Os pacotes são instalados ou atualizados para a versão mais recente disponível na distribuição atualmente disponível na sua máquina local. Para atualizar essa distribuição, junto com as ferramentas Guix, você deve executar guix pull: o comando baixa o código-fonte Guix mais recente e as descrições dos pacotes, e os implementa. O código-fonte é baixado de um repositório Git, por padrão o repositório oficial GNU Guix, embora isso possa ser personalizado. guix pull garante que o código que ele baixa é autêntico, verificando se os commits são assinados pelos desenvolvedores Guix.

Especificamente, guix pull baixa o código dos canais (veja Canais) especificados por um dos seguintes, nesta ordem:

1. a opção --channels;
2. o arquivo ~/.config/guix/channels.scm do usuário, a menos que -q seja passado;
3. o arquivo /etc/guix/channels.scm de todo o sistema, a menos que -q seja passado (no sistema Guix, este arquivo pode ser declarado na configuração do sistema operacional, veja campo channels de guix-configuration);
4. os canais padrão integrados especificados na variável %default-channels.

Após a conclusão, guix package usará pacotes e versões de pacotes desta cópia recém-recuperada do Guix. Não apenas isso, mas todos os comandos Guix e módulos Scheme também serão retirados dessa versão mais recente. Novos subcomandos guix adicionados pela atualização também se tornam disponíveis.

Qualquer usuário pode atualizar sua cópia do Guix usando guix pull, e o efeito é limitado ao usuário que executou guix pull. Por exemplo, quando o usuário root executa guix pull, isso não tem efeito na versão do Guix que o usuário alice vê, e vice-versa.

O resultado da execução de guix pull é um perfil disponível em ~/.config/guix/current contendo o Guix mais recente.

A opção --list-generations ou -l lista gerações anteriores produzidas por guix pull, juntamente com detalhes sobre sua procedência:

$ guix pull -l
Geração 1	10 jun 2018 00:18:18
  guix 65956ad
    URL do repositório: https://git.savannah.gnu.org/git/guix.git
    ramo: origin/master
    commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

Geração 2	11 jun 2018 11:02:49
  guix e0cc7f6
    URL do repositório: https://git.savannah.gnu.org/git/guix.git
    ramo: origin/master
    commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d

Geração 3	13 jun 2018 23:31:07	(atual)
  guix 844cc1c
    URL do repositório: https://git.savannah.gnu.org/git/guix.git
    ramo: origin/master
    commit: 844cc1c8f394f03b404c5bb3aee086922373490c

Veja guix describe, para outras maneiras de descrever o status atual do Guix.

Este perfil ~/.config/guix/current funciona exatamente como os perfis criados por guix package (veja Invocando guix package). Ou seja, você pode listar gerações, reverter para a geração anterior — ou seja, o Guix anterior — e assim por diante:

$ guix pull --roll-back
trocado da geração 3 para 2
$ guix pull --delete-generations=1
excluindo /var/guix/profiles/per-user/charlie/current-guix-1-link

Você também pode usar guix package (veja Invocando guix package) para gerenciar o perfil nomeando-o explicitamente:

$ guix package -p ~/.config/guix/current --roll-back
trocado da geração 3 para 2
$ guix package -p ~/.config/guix/current --delete-generations=1
excluindo /var/guix/profiles/per-user/charlie/current-guix-1-link

O comando guix pull geralmente é invocado sem argumentos, mas suporta as seguintes opções:

--url=url

--commit=commit

--branch=ramo

Baixe o código para o canal guix do url especificado, no commit fornecido (um ID de commit Git válido representado como uma string hexadecimal ou o nome de uma tag) ou ramo.

Essas opções são fornecidas para sua conveniência, mas você também pode especificar sua configuração no arquivo ~/.config/guix/channels.scm ou usando a opção --channels (veja abaixo).

--channels=arquivo

-C arquivo

Leia a lista de canais de arquivo em vez de ~/.config/guix/channels.scm ou /etc/guix/channels.scm. arquivo deve conter código Scheme que avalia uma lista de objetos de canal. Veja Canais, para mais informações.

--no-channel-files

-q

Inibir o carregamento dos arquivos de canal do usuário e do sistema, ~/.config/guix/channels.scm e /etc/guix/channels.scm.

--news

-N

Exibir notícias escritas por autores de canais para seus usuários para alterações feitas desde a geração anterior (veja Escrevendo Notícias de Canal). Quando --details é passado, exibir adicionalmente pacotes novos e atualizados.

Você pode visualizar essas informações de gerações anteriores com guix pull -l.

--list-generations[=padrão]

-l [padrão]

Liste todas as gerações de ~/.config/guix/current ou, se padrão for fornecido, o subconjunto de gerações que correspondem a padrão. A sintaxe de padrão é a mesma de guix package --list-generations (veja Invocando guix package).

Por padrão, isso imprime informações sobre os canais usados em cada revisão, bem como as entradas de notícias correspondentes. Se você passar --details, ele também imprimirá a lista de pacotes adicionados e atualizados em cada geração em comparação com a anterior.

--details

Instrua --list-generations ou --news para exibir mais informações sobre as diferenças entre gerações subsequentes — veja acima.

--roll-back ¶

Reverta para a geração anterior de ~/.config/guix/current—ou seja, desfaça a última transação.

--switch-generation=padrão ¶

-S padrão

Mude para uma geração específica definida por padrão.

padrão pode ser um número de geração ou um número prefixado com "+” ou "-”. O último significa: mover para frente/para trás por um número especificado de gerações. Por exemplo, se você quiser retornar para a última geração após --roll-back, use --switch-generation=+1.

--delete-generations[=padrão]

-d [padrão]

Quando padrão for omitido, exclua todas as gerações, exceto a atual.

Este comando aceita os mesmos padrões de --list-Generations. Quando pattern for especificado, exclua as gerações correspondentes. Quando padrão especifica uma duração, as gerações mais antigas que a duração especificada correspondem. Por exemplo, --delete-generations=1m exclui gerações com mais de um mês.

Se a geração atual corresponder, ela não será excluída.

Observe que a exclusão de gerações impede a reversão para elas. Conseqüentemente, este comando deve ser usado com cuidado.

Veja Invocando guix describe, para uma maneira de exibir informações somente sobre a geração atual.

--profile=perfil

-p perfil

Use perfil em vez de ~/.config/guix/current.

--dry-run

-n

Mostre quais commits de canal seriam usados e o que seria construído ou substituído, mas não faça isso de fato.

--allow-downgrades

Permitir extrair revisões de canais mais antigas ou não relacionadas às que estão em uso atualmente.

Por padrão, guix pull protege contra os chamados "ataques de downgrade”, nos quais o repositório Git de um canal seria redefinido para uma revisão anterior ou não relacionada a si mesmo, potencialmente levando você a instalar versões mais antigas e conhecidas de pacotes de software.

Nota: Certifique-se de entender as implicações de segurança antes de usar --allow-downgrades.

--disable-authentication

Permitir extrair código de canal sem autenticá-lo.

Por padrão, guix pull autentica o código baixado de canais verificando se seus commits são assinados por desenvolvedores autorizados e gera um erro se esse não for o caso. Esta opção o instrui a não executar nenhuma verificação desse tipo.

Nota: Certifique-se de entender as implicações de segurança antes de usar --disable-authentication.

--no-check-certificate

Do not validate the X.509 certificates of HTTPS servers.

When using this option, you have absolutely no guarantee that you are communicating with the authentic server responsible for the given URL. Unless the channel is authenticated, this makes you vulnerable to “man-in-the-middle” attacks.

--system=sistema

-s sistema

Tente compilar para sistema—por exemplo, i686-linux—em vez do tipo de sistema do host de compilação.

--bootstrap

Use o bootstrap Guile para construir o Guix mais recente. Esta opção é útil somente para desenvolvedores Guix.

O mecanismo dos canais permite que você instrua guix pull de qual repositório e branch extrair, bem como repositórios adicionais contendo módulos de pacote que devem ser implantados. Veja Canais, para mais informações.

Além disso, guix pull suporta todas as opções de compilação comuns (veja Opções de compilação comuns).

5.8 Invocando guix time-machine

O comando guix time-machine fornece acesso a outras revisões do Guix, por exemplo, para instalar versões mais antigas de pacotes ou para reproduzir uma computação em um ambiente idêntico. A revisão do Guix a ser usada é definida por um commit ou por um arquivo de descrição de canal criado por guix describe (veja Invocando guix describe).

Vamos supor que você queira viajar para aqueles dias de novembro de 2020, quando a versão 1.2.0 do Guix foi lançada e, uma vez lá, executar o guile daquela época:

guix time-machine --commit=v1.2.0 -- \
  environment -C --ad-hoc guile -- guile

O comando acima busca Guix 1.2.0 (e possivelmente outros canais especificados pelos seus arquivos de configuração channels.scm — veja abaixo) e executa seu comando guix environment para gerar um ambiente em um contêiner executando guile (guix environment foi desde então subsumido por guix shell; veja Invocando guix shell). É como dirigir um DeLorean¹²! A primeira invocação de guix time-machine pode ser cara: pode ser necessário baixar ou até mesmo construir um grande número de pacotes; o resultado é armazenado em cache e os comandos subsequentes direcionados ao mesmo commit são quase instantâneos.

Quanto ao guix pull, na ausência de quaisquer opções, o time-machine busca os últimos commits dos canais especificados em ~/.config/guix/channels.scm, /etc/guix/channels.scm, ou os canais padrão; a opção -q permite que você ignore esses arquivos de configuração. O comando:

guix time-machine -q -- build hello

construirá então o pacote hello conforme definido no branch principal do Guix, sem nenhum canal adicional, que é em geral uma revisão mais nova do Guix do que a que você instalou. A viagem no tempo funciona em ambas as direções!

Nota: O histórico do Guix é imutável e guix time-machine fornece exatamente o mesmo software que eles estão em uma revisão específica do Guix. Naturalmente, nenhuma correção de segurança é fornecida para versões antigas do Guix ou seus canais. Um uso descuidado do guix time-machine abre a porta para vulnerabilidades de segurança. Veja --allow-downgrades.

guix time-machine gera um erro ao tentar viajar para commits mais antigos que "v0.16.0" (commit ‘4a0b87f0’), datados de Dez. 2018. Este é um dos commits mais antigos que oferecem suporte ao mecanismo de canal que torna a "viagem no tempo" possível.

Nota: Embora seja tecnicamente possível viajar para um commit tão antigo, a facilidade para fazê-lo dependerá em grande parte da disponibilidade de substitutos binários. Ao viajar para um passado distante, alguns pacotes podem não ser mais facilmente construídos a partir da fonte. Um exemplo são as versões antigas do OpenSSL cujos testes falhavam após uma certa data. Esse problema em particular pode ser contornado executando uma máquina de construção virtual com seu relógio ajustado para a hora certa (veja Máquinas de Construção Virtual).

A sintaxe geral é:

guix time-machine opções… -- comando arg…

onde comando e arg… são passados sem modificações para o comando guix da revisão especificada. As opções que definem esta revisão são as mesmas que para guix pull (veja Invocando guix pull):

--url=url

--commit=commit

--branch=ramo

Use o canal guix do url especificado, no commit fornecido (um ID de commit Git válido representado como uma string hexadecimal ou o nome de uma tag) ou ramo.

--channels=arquivo

-C arquivo

Leia a lista de canais de arquivo. arquivo deve conter código Scheme que avalia uma lista de objetos de canal. Veja Canais para mais informações.

--no-channel-files

-q

Inibir o carregamento dos arquivos de canal do usuário e do sistema, ~/.config/guix/channels.scm e /etc/guix/channels.scm.

Portanto, guix time-machine -q é equivalente ao seguinte comando Bash, usando a sintaxe "substituição de processo" (veja Process Substitution em Manual de referência do GNU Bash):

guix time-machine -C <(echo %default-channels) …

Observe que guix time-machine pode acionar compilações de canais e suas dependências, e elas são controladas pelas opções de compilação padrão (veja Opções de compilação comuns).

Se guix time-machine for executado sem nenhum comando, ele imprime o nome do arquivo do perfil que seria usado para executar o comando. Isso às vezes é útil se você precisa obter o nome do arquivo de armazém do perfil — por exemplo, quando você quer guix copy ele.

5.9 Inferiores

Nota: A funcionalidade descrita aqui é uma “prévia de tecnologia” da versão 4538aa4. Como tal, a interface está sujeita a alterações.

Às vezes, você pode precisar misturar pacotes da revisão do Guix que você está executando atualmente com pacotes disponíveis em uma revisão diferente do Guix. Os inferiores do Guix permite que você consiga isso compondo diferentes revisões do Guix de maneiras arbitrárias.

Tecnicamente, um “inferior” é essencialmente um processo Guix separado conectado ao seu processo Guix principal por meio de um REPL (veja Invocando guix repl). O módulo (guix inferior) permite que você crie inferiores e se comunique com eles. Ele também fornece uma interface de alto nível para navegar e manipular os pacotes que um inferior fornece—pacotes inferiores.

Quando combinados com canais (veja Canais), os inferiores fornecem uma maneira simples de interagir com uma revisão separada do Guix. Por exemplo, vamos supor que você queira instalar em seu perfil o pacote guile atual, junto com o guile-json como ele existia em uma revisão mais antiga do Guix—talvez porque o mais novo guile-json tenha uma API incompatível e você queira executar seu código contra a API antiga. Para fazer isso, você pode escrever um manifesto para uso por guix package --manifest (veja Escrevendo manifestos); nesse manifesto, você criaria um inferior para aquela revisão antiga do Guix que você se importa, e você procuraria o pacote guile-json no inferior:

(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))   ;para 'first'

(define canais
  ;; Esta é a revisão antiga da qual queremos
  ;; extrair guile-json.
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

(define inferior
  ;; Um inferior representando a revisão acima.
  (inferior-for-channels canais))

;; Agora crie um manifesto com o pacote "guile" atual
;; e o antigo pacote "guile-json".
(packages->manifest
 (list (first (lookup-inferior-packages inferior "guile-json"))
       (specification->package "guile")))

Na primeira execução, guix package --manifest pode ter que construir o canal que você especificou antes de poder criar o inferior; execuções subsequentes serão muito mais rápidas porque a revisão do Guix será armazenada em cache.

O módulo (guix inferior) fornece os seguintes procedimentos para abrir um inferior:

Procedimento: inferior-for-channels canais [#:cache-directory] [#:ttl]

Retorna um inferior para canais, uma lista de canais. Use o cache em cache-directory, onde as entradas podem ser recuperadas após ttl segundos. Este procedimento abre uma nova conexão com o daemon de construção.

Como efeito colateral, esse procedimento pode criar ou substituir binários para canais, o que pode levar tempo.

Procedimento: open-inferior diretório [#:command "bin/guix"]

Abra o Guix inferior em diretório, executando o comando diretório/command repl ou equivalente. Retorne #f se o inferior não puder ser iniciado.

Os procedimentos listados abaixo permitem que você obtenha e manipule pacotes inferiores.

Procedimento: inferior-packages inferior

Retorna a lista de pacotes conhecidos por inferior.

Procedimento: lookup-inferior-packages inferior nome [versão]

Retorna a lista ordenada de pacotes inferiores que correspondem a nome em inferior, com os números de versão mais altos primeiro. Se versão for true, retorna apenas pacotes com um número de versão prefixado por versão.

Procedimento: inferior-package? obj

Retorna verdadeiro se obj for um pacote inferior.

Procedimento: inferior-package-name pacote

Procedimento: inferior-package-version pacote

Procedimento: inferior-package-synopsis pacote

Procedimento: inferior-package-description pacote

Procedimento: inferior-package-home-page pacote

Procedimento: inferior-package-location pacote

Procedimento: inferior-package-inputs pacote

Procedimento: inferior-package-native-inputs pacote

Procedimento: inferior-package-propagated-inputs pacote

Procedimento: inferior-package-transitive-propagated-inputs pacote

Procedimento: inferior-package-native-search-paths pacote

Procedimento: inferior-package-transitive-native-search-paths pacote

Procedimento: inferior-package-search-paths pacote

Esses procedimentos são a contrapartida dos acessadores de registro de pacote (veja Referência do package). A maioria deles funciona consultando o inferior de onde pacote vem, então o inferior ainda deve estar ativo quando você chamar esses procedimentos.

Pacotes inferiores podem ser usados transparentemente como qualquer outro pacote ou objeto tipo arquivo em expressões-G (veja Expressões-G). Eles também são manipulados transparentemente pelo procedimento packages->manifest, que é comumente usado em manifestos (veja a opção --manifest de guix package). Assim, você pode inserir um pacote inferior praticamente em qualquer lugar em que inseriria um pacote regular: em manifestos, no campo packages da sua declaração operating-system e assim por diante.

5.10 Invocando guix describe

Frequentemente você pode querer responder perguntas como: “Qual revisão do Guix estou usando?” ou “Quais canais estou usando?” Essas são informações úteis em muitas situações: se você quiser replicar um ambiente em uma máquina ou conta de usuário diferente, se quiser relatar um bug ou determinar qual alteração nos canais que você está usando o causou, ou se quiser registrar o estado do seu sistema para fins de reprodutibilidade. O comando guix describe responde a essas perguntas.

Quando executado a partir de um guix obtido com guix pull, guix describe exibe o(s) canal(ais) dos quais foi criado, incluindo a URL do repositório e os IDs de confirmação (veja Canais):

$ guix describe
Geração 10	03 set 2018 17:32:44	(atual)
  guix e0fa68c
    URL do repositório: https://git.savannah.gnu.org/git/guix.git
    ramo: master
    commit: e0fa68c7718fffd33d81af415279d6ddb518f727

Se você estiver familiarizado com o sistema de controle de versão do Git, isso é similar em espírito a git describe; a saída também é similar à de guix pull --list-generations, mas limitada à geração atual (veja a opção --list-generations). Como o ID de commit do Git mostrado acima se refere inequivocamente a um snapshot do Guix, essa informação é tudo o que é preciso para descrever a revisão do Guix que você está usando e também para replicá-la.

Para facilitar a replicação do Guix, guix describe também pode ser solicitado a retornar uma lista de canais em vez da descrição legível acima:

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

Você pode salvar isso em um arquivo e alimentá-lo com guix pull -C em alguma outra máquina ou em um momento posterior, o que instanciará esta revisão exata do Guix (veja a opção -C). A partir daí, já que você consegue implementar a mesma revisão do Guix, você pode muito bem replicar um ambiente de software completo. Humildemente achamos isso incrível, e esperamos que você goste também!

Os detalhes das opções suportadas por guix describe são os seguintes:

--format=formato

-f formato

Produza saída no formato especificado, um dos seguintes:

human

produzir resultados legíveis por humanos;

channels

produz uma lista de especificações de canal que podem ser passadas para guix pull -C ou instaladas como ~/.config/guix/channels.scm (veja Invocando guix pull);

channels-sans-intro

como channels, mas omita o campo introduction; use-o para produzir uma especificação de canal adequada para a versão 1.1.0 do Guix ou anterior — o campo introduction tem a ver com autenticação de canal (veja Autenticação de canal) e não é suportado por essas versões mais antigas;

json ¶

produzir uma lista de especificações de canal no formato JSON;

recutils

produzir uma lista de especificações de canais no formato Recutils.

--list-formats

Exibir formatos disponíveis para a opção --format.

--profile=perfil

-p perfil

Exibir informações sobre perfil.

5.11 Invocando guix archive

O comando guix archive permite que os usuários exportem arquivos do armazém para um único arquivamento e depois importem eles em uma máquina que execute o Guix. Em particular, ele permite que os arquivos do armazém sejam transferidos de uma máquina para o store em outra máquina.

Nota: Se você estiver procurando uma maneira de produzir arquivamentos em um formato adequado para outras ferramentas além do Guix, veja Invocando guix pack.

Para exportar arquivos de armazém como um arquivamento para saída padrão, execute:

guix archive --export opções especificações...

especificações pode ser nomes de arquivos de armazém ou especificações de pacotes, como para guix package (veja Invocando guix package). Por exemplo, o comando a seguir cria um arquivo contendo a saída gui do pacote git e a saída principal de emacs:

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

Se os pacotes especificados ainda não foram construídos, guix archive os constrói automaticamente. O processo de construção pode ser controlado com as opções comuns de construção (veja Opções de compilação comuns).

Para transferir o pacote emacs para uma máquina conectada via SSH, execute:

guix archive --export -r emacs | ssh a-máquina guix archive --import

Da mesma forma, um perfil de usuário completo pode ser transferido de uma máquina para outra assim:

guix archive --export -r $(readlink -f ~/.guix-profile) | \
  ssh a-máquina guix archive --import

No entanto, observe que, em ambos os exemplos, todos os emacs e o perfil, bem como todas as suas dependências são transferidos (devido a -r), independentemente do que já esteja disponível no armazém na máquina de destino. A opção --missing pode ajudar a descobrir quais itens estão faltando no armazém de destino. O comando guix copy simplifica e otimiza todo esse processo, então é provavelmente isso que você deve usar neste caso (veja Invocando guix copy).

Cada item do armazém é escrito no formato arquivamento normalizado ou nar (descrito abaixo), e a saída de guix archive --export (e entrada de guix archive --import) é uma embalagem nar.

O formato nar é comparável em espírito ao ‘tar’, mas com diferenças que o tornam mais apropriado para nossos propósitos. Primeiro, em vez de registrar todos os metadados Unix para cada arquivo, o formato nar menciona apenas o tipo de arquivo (regular, diretório ou ligação simbólica); permissões Unix e proprietário/grupo são descartados. Segundo, a ordem em que as entradas de diretório são armazenadas sempre segue a ordem dos nomes de arquivo de acordo com a ordem de agrupamento de localidade C. Isso torna a produção de arquivo totalmente determinística.

O formato da embalagem nar é essencialmente a concatenação de zero ou mais nars junto com metadados para cada item de armazém que ele contém: seu nome de arquivo, referências, derivação correspondente e uma assinatura digital.

Ao exportar, o daemon assina digitalmente o conteúdo do arquivamento, e essa assinatura digital é anexada. Ao importar, o daemon verifica a assinatura e rejeita a importação em caso de uma assinatura inválida ou se a chave de assinatura não for autorizada.

As principais opções são:

--export

Exporte os arquivos de armazém ou pacotes especificados (veja abaixo). Grave o arquivo resultante na saída padrão.

Dependências não são incluídas na saída, a menos que --recursive seja passado.

-r

--recursive

Quando combinado com --export, isso instrui guix archive a incluir dependências dos itens fornecidos no arquivo. Assim, o arquivo resultante é autocontido: ele contém o fechamento dos itens exportados do armazém.

--import

Leia um arquivo da entrada padrão e importe os arquivos listados nele para o armazém. Aborte se o arquivo tiver uma assinatura digital inválida ou se for assinado por uma chave pública que não esteja entre as chaves autorizadas (veja --authorize abaixo).

--missing

Leia uma lista de nomes de arquivos do armazém da entrada padrão, um por linha, e escreva na saída padrão o subconjunto desses arquivos que faltam no armazém.

--generate-key[=parâmetros] ¶

Gere um novo par de chaves para o daemon. Este é um pré-requisito antes que os arquivos possam ser exportados com --export. Esta operação é geralmente instantânea, mas pode levar algum tempo se o pool de entropia do sistema precisar ser recarregado. No Guix System, guix-service-type cuida da geração deste par de chaves na primeira inicialização.

O par de chaves gerado é normalmente armazenado em /etc/guix, em signing-key.pub (chave pública) e signing-key.sec (chave privada, que deve ser mantida em segredo). Quando parâmetros é omitido, uma chave ECDSA usando a curva Ed25519 é gerada ou, para versões do Libgcrypt anteriores a 1.6.0, é uma chave RSA de 4096 bits. Como alternativa, parâmetros pode especificar parâmetros genkey adequados para Libgcrypt (veja gcry_pk_genkey em Manual de referência do Libgcrypt).

--authorize ¶

Autorize importações assinadas pela chave pública passada na entrada padrão. A chave pública deve estar em “s-expression advanced format”—i.e., o mesmo formato do arquivo signing-key.pub.

A lista de chaves autorizadas é mantida no arquivo editável por humanos /etc/guix/acl. O arquivo contém “advanced-format s-expressions” e é estruturado como uma lista de controle de acesso no Simple Public-Key Infrastructure (SPKI).

--extract=diretório

-x diretório

Leia um arquivo de item único conforme servido por servidores substitutos (veja Substitutos) e extraia-o para diretório. Esta é uma operação de baixo nível necessária apenas em casos de uso muito restritos; veja abaixo.

Por exemplo, o comando a seguir extrai o substituto para o Emacs servido por bordeaux.guix.gnu.org para /tmp/emacs:

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

Arquivamentos de item único são diferentes de arquivamentos de itens múltiplos produzidos por guix archive --export; eles contêm um único item de armazém e não incorporam uma assinatura. Portanto, essa operação não faz nenhuma verificação de assinatura e sua saída deve ser considerada insegura.

O objetivo principal desta operação é facilitar a inspeção de conteúdos de arquivamento provenientes de servidores substitutos possivelmente não confiáveis (veja Invocando guix challenge).

--list

-t

Leia um arquivamento de item único servido por servidores substitutos (veja Substitutos) e exiba a lista de arquivos que ele contém, como neste exemplo:

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

6.1 Especificando canais adicionais

Você pode especificar canais adicionais para puxar. Para usar um canal, escreva ~/.config/guix/channels.scm para instruir guix pull para puxar dele além do(s) canal(ais) Guix padrão:

;; Adicione pacotes variantes aos fornecidos pelo Guix.
(cons (channel
        (name 'variant-packages)
        (url "https://example.org/variant-packages.git"))
      %default-channels)

Note que o snippet acima é (como sempre!) código do Scheme; usamos cons para adicionar um canal à lista de canais aos quais a variável %default-channels está vinculada (veja cons and lists em GNU Guile Reference Manual). Com esse arquivo no lugar, guix pull compila não apenas o Guix, mas também os módulos do pacote do seu próprio repositório. O resultado em ~/.config/guix/current é a união do Guix com seus próprios módulos do pacote:

$ guix describe
Geração 19	27 ago 2018 16:20:48
  guix d894ab8
    URL do repositório: https://git.savannah.gnu.org/git/guix.git
    ramo: master
    commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
  variant-packages dd3df5e
    URL do repositório: https://example.org/variant-packages.git
    ramo: master
    commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb

A saída do guix describe acima mostra que agora estamos executando o geração 19 e que ele inclui o Guix e os pacotes do canal variant-packages (veja Invocando guix describe).

6.2 Usando um canal Guix personalizado

O canal chamado guix especifica onde o próprio Guix—suas ferramentas de linha de comando, bem como sua coleção de pacotes—deve ser baixado. Por exemplo, suponha que você queira atualizar de outra cópia do repositório Guix em example.org, e especificamente o branch super-hacks, você pode escrever em ~/.config/guix/channels.scm esta especificação:

;; Diga ao 'guix pull' para usar outro repositório.
(list (channel
        (name 'guix)
        (url "https://example.org/another-guix.git")
        (branch "super-hacks")))

A partir daí, guix pull buscará o código do branch super-hacks do repositório em example.org. A preocupação com a autenticação é abordada abaixo (veja Autenticação de canal).

Note que você pode especificar um diretório local no campo url acima se o canal que você pretende usar residir em um sistema de arquivos local. No entanto, neste caso, guix verifica o diretório em busca de propriedade antes de qualquer processamento posterior. Isso significa que se o usuário não for o proprietário do diretório, mas quiser usá-lo como padrão, ele precisará defini-lo como um diretório seguro em seu arquivo de configuração global do git. Caso contrário, guix se recusará até mesmo a lê-lo. Supondo que seu diretório local de todo o sistema esteja em /src/guix.git, você criaria um arquivo de configuração do git em ~/.gitconfig com o seguinte conteúdo:

[safe]
        directory = /src/guix.git

Isso também se aplica ao usuário root, a menos que seja chamado com sudo pelo proprietário do diretório.

6.3 Replicando Guix

O comando guix describe mostra precisamente quais commits foram usados para construir a instância do Guix que estamos usando (veja Invocando guix describe). Podemos replicar essa instância em outra máquina ou em um ponto diferente no tempo fornecendo uma especificação de canal “fixada” a esses commits que se parece com isso:

;; Implantar commits específicos dos meus canais de interesse.
(list (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (commit "6298c3ffd9654d3231a6f25390b056483e8f407c"))
      (channel
       (name 'variant-packages)
       (url "https://example.org/variant-packages.git")
       (commit "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

Para obter essa especificação de canal fixado, a maneira mais fácil é executar guix describe e salvar sua saída no formato channels em um arquivo, assim:

guix describe -f channels > channels.scm

O arquivo channels.scm resultante pode ser passado para a opção -C de guix pull (veja Invocando guix pull) ou guix time-machine (veja Invocando guix time-machine), como neste exemplo:

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

Dado o arquivo channels.scm, o comando acima sempre buscará a exatamente a mesma instância Guix, então usará essa instância para executar exatamente o mesmo Python (veja Invocando guix shell). Em qualquer máquina, a qualquer momento, ele acaba executando exatamente os mesmos binários, bit por bit.

Os canais fixados abordam um problema semelhante a “arquivos de bloqueio” conforme implementado por algumas ferramentas de implantação — eles permitem que você fixe e reproduza um conjunto de pacotes. No caso do Guix, no entanto, você está efetivamente fixando o conjunto de pacotes inteiro conforme definido nos commits de canal fornecidos; na verdade, você está fixando todo o Guix, incluindo seus módulos principais e ferramentas de linha de comando. Você também está obtendo fortes garantias de que está, de fato, obtendo exatamente o mesmo software.

Isso lhe dá superpoderes, permitindo que você rastreie a procedência de artefatos binários com granularidade muito fina e reproduza ambientes de software à vontade — algum tipo de capacidade de “meta reprodutibilidade”, se preferir. Veja Inferiores, para outra maneira de aproveitar esses superpoderes.

6.4 Customizing the System-Wide Guix

Se você estiver executando o Guix System ou construindo imagens de sistema com ele, talvez você queira personalizar o guix de todo o sistema que ele fornece—especificamente, /run/current-system/profile/bin/guix. Por exemplo, você pode querer fornecer canais adicionais ou fixar sua revisão.

Isso pode ser feito usando o procedimento guix-for-channels, que retorna um pacote para os canais fornecidos e o usa como parte da configuração do seu sistema operacional, como neste exemplo:

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

(define my-channels
  ;; Canais que devem estar disponíveis para
  ;; /run/current-system/profile/bin/guix.
  (append
   (list (channel
          (name 'guix-science)
          (url "https://github.com/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)))))))

O sistema operacional resultante terá os canais guix e guix-science visíveis por padrão. O campo channels de guix-configuration acima garante ainda mais que /etc/guix/channels.scm, que é usado por guix pull, especifica o mesmo conjunto de canais (veja campo channels de guix-configuration).

O módulo (gnu packages package-management) exporta o procedimento guix-for-channels, descrito abaixo.

Procedimento: guix-for-channels canais

Retorna um pacote correspondente a canais.

O resultado é um pacote “regular”, que pode ser usado em guix-configuration como mostrado acima ou em qualquer outro lugar que espere um pacote.

6.5 Autenticação de canal

Os comandos guix pull e guix time-machine autenticam o código recuperado dos canais: eles garantem que cada commit que é buscado seja assinado por um desenvolvedor autorizado. O objetivo é proteger contra modificações não autorizadas no canal que levariam os usuários a executar código malicioso.

Como usuário, você deve fornecer uma introdução de canal no seu arquivo de canais para que o Guix saiba como autenticar seu primeiro commit. Uma especificação de canal, incluindo sua introdução, parece algo como estas linhas:

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

A especificação acima mostra o nome e a URL do canal. A chamada para make-channel-introduction acima especifica que a autenticação deste canal começa no commit 6f0d8cc…, que é assinado pela chave OpenPGP com impressão digital CABB A931….

Para o canal principal, chamado guix, você obtém automaticamente essas informações da sua instalação Guix. Para outros canais, inclua a introdução do canal fornecida pelos autores do canal no seu arquivo channels.scm. Certifique-se de recuperar a introdução do canal de uma fonte confiável, pois essa é a raiz da sua confiança.

Se você está curioso sobre a mecânica de autenticação, continue lendo!

6.6 Canais com substitutos

Ao executar guix pull, o Guix primeiro compilará as definições de cada pacote disponível. Esta é uma operação cara para a qual substitutos (veja Substitutos) podem estar disponíveis. O seguinte snippet em channels.scm garantirá que o guix pull use o commit mais recente com substitutos disponíveis para as definições de pacote: isso é feito consultando o servidor de integração contínua em https://ci.guix.gnu.org.

(use-modules (guix ci))

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

Note que isso não significa que todos os pacotes que você instalará após executar guix pull terão substitutos disponíveis. Isso apenas garante que guix pull não tentará compilar definições de pacotes. Isso é particularmente útil ao usar máquinas com recursos limitados.

6.7 Criando um canal

Digamos que você tenha um monte de variantes de pacotes personalizados ou pacotes pessoais que você acha que faria pouco sentido contribuir para o projeto Guix, mas gostaria de ter esses pacotes disponíveis de forma transparente para você na linha de comando. Ao criar um canal, você pode usar e publicar tal coleção de pacotes. Isso envolve as seguintes etapas:

1. Um canal fica em um repositório Git, então o primeiro passo, ao criar um canal, é criar seu repositório:

   mkdir meu-canal
   cd meu-canal
   git init
   

2. O próximo passo é criar arquivos contendo módulos de pacote (veja Módulos de pacote), cada um dos quais conterá uma ou mais definições de pacote (veja Definindo pacotes). Um canal pode fornecer coisas além de pacotes, como sistemas de compilação ou serviços; estamos usando pacotes, pois é o caso de uso mais comum.

   Por exemplo, Alice pode querer fornecer um módulo chamado (alice packages greetings) que fornecerá suas implementações favoritas de “hello world”. Para fazer isso, Alice criará um diretório correspondente ao nome desse módulo.

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

   Você pode nomear seus módulos de pacote como quiser; a principal restrição a ter em mente é evitar conflitos de nomes com outras coleções de pacotes, e é por isso que nossa hipotética Alice sabiamente escolheu o namespace (alice packages …).

   Observe que você também pode colocar módulos em um subdiretório do repositório; veja Módulos de pacote em um subdiretório, para mais informações sobre isso.

3. Com este primeiro módulo em funcionamento, o próximo passo é testar os pacotes que ele fornece. Isso pode ser feito com guix build, que precisa ser informado para procurar módulos no checkout do Git. Por exemplo, supondo que (alice packages greetings) forneça um pacote chamado hi-from-alice, Alice executará este comando do checkout do Git:

   guix build -L. hi-from-alice
   

   ... onde -L. adiciona o diretório atual ao caminho de carregamento do Guile (veja Load Paths em Manual de referência do GNU Guile).

4. Pode levar algumas iterações para Alice obter definições de pacote satisfatórias. Eventualmente, Alice fará commit deste arquivo:

   git commit
   

   Como autor de um canal, considere agrupar material de autenticação com seu canal para que os usuários possam autenticá-lo. Veja Autenticação de canal e Especificando autorizações de canal para obter informações sobre como fazer isso.

5. Para usar o canal de Alice, qualquer pessoa pode adicioná-lo ao seu arquivo de canal (veja Especificando canais adicionais) e executar guix pull (veja Invocando guix pull):

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

   Guix agora se comportará como se o diretório raiz do repositório Git daquele canal tivesse sido adicionado permanentemente ao caminho de carregamento do Guile. Neste exemplo, (alice packages greetings) será encontrado automaticamente pelo comando guix.

Voilà!

Aviso: Antes de publicar seu canal, gostaríamos de compartilhar algumas palavras de cautela:

• Antes de publicar um canal, considere contribuir com suas definições de pacote para o Guix propriamente dito (veja Contribuindo). O Guix como um projeto é aberto a software livre de todos os tipos, e os pacotes no Guix propriamente dito estão prontamente disponíveis para todos os usuários do Guix e se beneficiam do processo de garantia de qualidade do projeto.
• Módulos de pacote e definições de pacote são códigos Scheme que usam várias interfaces de programação (APIs). Nós, desenvolvedores Guix, nunca mudamos APIs gratuitamente, mas também não nos comprometemos a congelar APIs. Quando você mantém definições de pacote fora do Guix, consideramos que o fardo da compatibilidade é seu.
• Corolário: se você estiver usando um canal externo e esse canal quebrar, reporte o problema aos autores do canal, não ao projeto Guix.

Você foi avisado! Dito isso, acreditamos que canais externos são uma maneira prática de exercer sua liberdade para aumentar a coleção de pacotes do Guix e compartilhar suas melhorias, que são princípios básicos do software livre. Por favor, envie um e-mail para guix-devel@gnu.org se você quiser discutir isso.

6.8 Módulos de pacote em um subdiretório

Como autor de canal, você pode querer manter seus módulos de canal em um subdiretório. Se seus módulos estiverem no subdiretório guix, você deve adicionar um arquivo de metadados .guix-channel que contenha:

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

Os módulos devem estar abaixo do diretório especificado, pois o diretório directory altera o load-path do Guile. Por exemplo, se .guix-channel tiver (directory "base"), então um módulo definido como (define-module (gnu packages fun)) deve estar localizado em base/gnu/packages/fun.scm.

Fazer isso permite que apenas partes de um repositório sejam usadas como um canal, pois o Guix espera módulos Guile válidos ao puxar. Por exemplo, os arquivos de configuração de máquina guix deploy não são módulos Guile válidos, e tratá-los como tal faria com que guix pull falhasse.

6.9 Declarando dependências de canal

Os autores de canais podem decidir aumentar uma coleção de pacotes fornecida por outros canais. Eles podem declarar que seu canal é dependente de outros canais em um arquivo de metadados .guix-channel, que deve ser colocado na raiz do repositório do canal.

O arquivo de metadados deve conter uma expressão S simples como esta:

(channel
 (version 0)
 (dependencies
  (channel
   (name algum-coleção)
   (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"))))

No exemplo acima, este canal é declarado para depender de dois outros canais, que serão buscados automaticamente. Os módulos fornecidos pelo canal serão compilados em um ambiente onde os módulos de todos esses canais declarados estão disponíveis.

Por uma questão de confiabilidade e manutenibilidade, você deve evitar dependências em canais que você não controla e deve tentar manter o número de dependências no mínimo.

6.10 Especificando autorizações de canal

Como vimos acima, o Guix garante que o código-fonte que ele extrai dos canais vem de desenvolvedores autorizados. Como autor de um canal, você precisa especificar a lista de desenvolvedores autorizados no arquivo .guix-authorizations no repositório Git do canal. A regra de autenticação é simples: cada commit deve ser assinado por uma chave listada no arquivo .guix-authorizations de seu(s) commit(s) pai(s)¹³ O arquivo .guix-authorizations se parece com isso:

;; Exemplo de arquivo '.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"))))

Cada impressão digital é seguida por pares chave/valor opcionais, como no exemplo acima. Atualmente, esses pares chave/valor são ignorados.

Esta regra de autenticação cria um problema do tipo "ovo e galinha": como autenticamos o primeiro commit? Relacionado a isso: como lidamos com canais cujo histórico de repositório contém commits não assinados e não tem .guix-authorizations? E como bifurcamos canais existentes?

As introduções de canal respondem a essas perguntas descrevendo o primeiro commit de um canal que deve ser autenticado. Na primeira vez que um canal é buscado com guix pull ou guix time-machine, o comando procura o commit introdutório e verifica se ele está assinado pela chave OpenPGP especificada. A partir daí, ele autentica os commits de acordo com a regra acima. A autenticação falha se o commit de destino não for descendente nem ancestral do commit introdutório.

Além disso, seu canal deve fornecer todas as chaves OpenPGP que já foram mencionadas em .guix-authorizations, armazenadas como arquivos .key, que podem ser binários ou “ASCII-armored”. Por padrão, esses arquivos .key são pesquisados no branch chamado keyring, mas você pode especificar um nome de branch diferente em .guix-channel assim:

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

Para resumir, como autor de um canal, há três coisas que você precisa fazer para permitir que os usuários autentiquem seu código:

1. Exporte as chaves OpenPGP de contribuidores anteriores e atuais com gpg --export e armazene-as em arquivos .key, por padrão em uma ramificação chamada keyring (recomendamos torná-la uma ramificação órfã).
2. Introduza um .guix-authorizations inicial no repositório do canal. Faça isso em um commit assinado (veja Confirmar acesso, para obter informações sobre como assinar commits do Git).
3. Anuncie a introdução do canal, por exemplo, na página web do seu canal. A introdução do canal, como vimos acima, é o par commit/chave—i.e., o commit que introduziu .guix-authorizations, e a impressão digital do OpenPGP usada para assiná-lo.

Antes de enviar para seu repositório Git público, você pode executar guix git authenticate para verificar se você assinou todos os commits que está prestes a enviar com uma chave autorizada:

guix git authenticate commit signer

onde commit e signer são a introdução do seu canal. Veja Invocando guix git authenticate, para detalhes.

Publicar um canal assinado requer disciplina: qualquer erro, como um commit não assinado ou um commit assinado por uma chave não autorizada, impedirá que usuários puxem do seu canal — bem, esse é o ponto principal da autenticação! Preste atenção às mesclagens em particular: commits de mesclagem são considerados autênticos se e somente se forem assinados por uma chave presente no arquivo .guix-authorizations de ambos os ramos.

6.11 URL principal

Os autores do canal podem indicar a URL principal do repositório Git do canal no arquivo .guix-channel, assim:

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

Isso permite que guix pull determine se está puxando código de um espelho do canal; quando esse for o caso, ele avisa o usuário que o espelho pode estar obsoleto e exibe a URL primária. Dessa forma, os usuários não podem ser enganados para buscar código de um espelho obsoleto que não recebe atualizações de segurança.

Esse recurso só faz sentido para repositórios autenticados, como o canal oficial guix, para o qual guix pull garante que o código que ele recupera é autêntico.

6.12 Escrevendo notícias do canal

Os autores do canal podem ocasionalmente querer comunicar aos seus usuários informações sobre mudanças importantes no canal. Você enviaria um e-mail para todos eles, mas isso não é conveniente.

Em vez disso, os canais podem fornecer um arquivo de notícias; quando os usuários do canal executam guix pull, esse arquivo de notícias é lido automaticamente e guix pull --news pode exibir os anúncios que correspondem aos novos commits que foram extraídos, se houver.

Para fazer isso, os autores do canal devem primeiro declarar o nome do arquivo de notícias em seu arquivo .guix-channel:

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

O arquivo de notícias em si, etc/news.txt neste exemplo, deve ser parecido com isto:

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

Enquanto o arquivo de notícias estiver usando a sintaxe Scheme, evite nomeá-lo com uma extensão .scm ou então ele será pego ao construir o canal e gerará um erro, pois não é um módulo válido. Como alternativa, você pode mover o módulo do canal para um subdiretório e armazenar o arquivo de notícias em outro diretório.

O arquivo consiste em uma lista de entradas de notícias. Cada entrada é associada a um commit ou tag: ela descreve as alterações feitas neste commit, possivelmente em commits anteriores também. Os usuários veem as entradas somente na primeira vez que obtêm o commit ao qual a entrada se refere.

O campo title deve ser um resumo de uma linha, enquanto body pode ser arbitrariamente longo, e ambos podem conter marcação Texinfo (veja Overview em GNU Texinfo). Tanto o título quanto o corpo são uma lista de tuplas de tag/mensagem de idioma, o que permite que guix pull exiba notícias no idioma que corresponde à localidade do usuário.

Se você quiser traduzir notícias usando um fluxo de trabalho baseado em gettext, você pode extrair strings traduzíveis com xgettext (veja xgettext Invocation em GNU Gettext Utilities). Por exemplo, supondo que você escreva entradas de notícias em inglês primeiro, o comando abaixo cria um arquivo PO contendo as strings a serem traduzidas:

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

Para resumir, sim, você pode usar seu canal como um blog. Mas cuidado, isso é não é bem o que seus usuários podem esperar.

7.1 Invocando guix shell

O propósito do guix shell é facilitar a criação de ambientes de software únicos, sem alterar o perfil. Ele é normalmente usado para criar ambientes de desenvolvimento; também é uma maneira conveniente de executar aplicativos sem “poluir” seu perfil.

Nota: O comando guix shell foi introduzido recentemente para substituir guix environment (veja Invocando guix environment). Se você estiver familiarizado com guix environment, notará que ele é semelhante, mas também—esperamos!—mais conveniente.

A sintaxe geral é:

guix shell [opções] [pacote…]

Às vezes, uma sessão de shell interativa não é desejada. Um comando arbitrário pode ser invocado colocando o token -- para separar o comando do resto dos argumentos.

O exemplo a seguir cria um ambiente contendo Python e NumPy, compilando ou baixando qualquer pacote ausente e executa o comando python3 nesse ambiente:

guix shell python python-numpy -- python3

Note que é necessário incluir o pacote principal python neste comando, mesmo que ele já esteja instalado em seu ambiente. Isso é para que o ambiente shell saiba definir PYTHONPATH e outras variáveis relacionadas. O ambiente shell não pode verificar o ambiente instalado anteriormente, porque então seria não determinístico. Isso é verdade para a maioria das bibliotecas: seu pacote de linguagem correspondente deve ser incluído na invocação do shell.

Nota: guix shell também pode ser usado como um interpretador de script, também conhecido como shebang. Aqui está um exemplo de script Python autocontido fazendo uso desse recurso:

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

Você pode passar qualquer opção guix shell, mas há uma ressalva: o kernel Linux tem um limite de 127 bytes no comprimento do shebang.

Ambientes de desenvolvimento podem ser criados como no exemplo abaixo, que gera um shell interativo contendo todas as dependências e variáveis de ambiente necessárias para trabalhar no Inkscape:

guix shell --development inkscape

Sair do shell coloca o usuário de volta no ambiente original antes de guix shell ser invocado. A próxima coleta de lixo (veja Invocando guix gc) pode limpar pacotes que foram instalados no ambiente e que não são mais usados fora dele.

Como uma conveniência adicional, guix shell tentará fazer o que você quer dizer quando for invocado interativamente sem nenhum outro argumento, como em:

guix shell

Se encontrar um manifest.scm no diretório de trabalho atual ou em qualquer um dos seus pais, ele usa esse manifesto como se tivesse sido fornecido via --manifest. Da mesma forma, se encontrar um guix.scm nos mesmos diretórios, ele o usa para construir um perfil de desenvolvimento como se --development e --file estivessem presentes. Em ambos os casos, o arquivo só será carregado se o diretório em que ele reside estiver listado em ~/.config/guix/shell-authorized-directories. Isso fornece uma maneira fácil de definir, compartilhar e entrar em ambientes de desenvolvimento.

Por padrão, a sessão ou comando do shell é executado em um ambiente aumentado, onde os novos pacotes são adicionados às variáveis de ambiente do caminho de pesquisa, como PATH. Em vez disso, você pode escolher criar um ambiente isolado contendo apenas os pacotes solicitados. Passar a opção --pure limpa as definições de variáveis de ambiente encontradas no ambiente pai¹⁴; passar --container vai um passo além ao gerar um contêiner isolado do resto do sistema:

guix shell --container emacs gcc-toolchain

O comando acima gera um shell interativo em um contêiner onde nada além de emacs, gcc-toolchain e suas dependências estão disponíveis. O contêiner não tem acesso à rede e não compartilha nenhum arquivo além do diretório de trabalho atual com o ambiente ao redor. Isso é útil para evitar acesso a recursos de todo o sistema, como /usr/bin em distros estrangeiras.

Esta opção --container também pode ser útil se você deseja executar um aplicativo sensível à segurança, como um navegador da web, em um ambiente isolado. Por exemplo, o comando abaixo inicia o Ungoogled-Chromium em um ambiente isolado, que:

• compartilha o acesso à rede com o host
• herda as variáveis de ambiente do host DISPLAY e XAUTHORITY
• tem acesso aos registros de autenticação do host do XAUTHORITY file
• não tem informações sobre o diretório atual do host

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

guix shell define a variável GUIX_ENVIRONMENT no shell que ele gera; seu valor é o nome do arquivo do perfil deste ambiente. Isso permite que os usuários, digamos, definam um prompt específico para ambientes de desenvolvimento em seu .bashrc (veja Bash Startup Files em Manual de referência do GNU Bash):

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

... ou para navegar pelo perfil:

$ ls "$GUIX_ENVIRONMENT/bin"

As opções disponíveis estão resumidas abaixo.

--check

Configure o ambiente e verifique se o shell sobrecarregaria as variáveis de ambiente. É uma boa ideia usar esta opção na primeira vez que você executar guix shell para uma sessão interativa para garantir que sua configuração esteja correta.

Por exemplo, se o shell modificar a variável de ambiente PATH, informe isso, pois você obterá um ambiente diferente do que solicitou.

Tais problemas geralmente indicam que os arquivos de inicialização do shell estão modificando inesperadamente essas variáveis de ambiente. Por exemplo, se você estiver usando Bash, certifique-se de que as variáveis de ambiente estejam definidas ou modificadas em ~/.bash_profile e não em ~/.bashrc—o primeiro é originado apenas por shells de login. Veja Bash Startup Files em Manual de referência do GNU Bash, para detalhes sobre os arquivos de inicialização do Bash.

--development

-D

Faça com que guix shell inclua no ambiente as dependências do pacote a seguir em vez do pacote em si. Isso pode ser combinado com outros pacotes. Por exemplo, o comando abaixo inicia um shell interativo contendo as dependências de tempo de compilação do GNU Guile, além do Autoconf, Automake e Libtool:

guix shell -D guile autoconf automake libtool

--expression=expr

-e expr

Crie um ambiente para o pacote ou lista de pacotes que expr avalia.

Por exemplo, executando:

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

inicia um shell com o ambiente para esta variante específica do pacote PETSc.

Rodando:

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

inicia um shell com todos os pacotes do sistema base disponíveis.

Os comandos acima usam apenas a saída padrão dos pacotes fornecidos. Para selecionar outras saídas, duas tuplas de elementos podem ser especificadas:

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

Veja package->development-manifest, para obter informações sobre como escrever um manifesto para o ambiente de desenvolvimento de um pacote.

--file=arquivo

-f arquivo

Crie um ambiente contendo o pacote ou lista de pacotes que o código dentro de arquivo avalia.

Por exemplo, arquivo pode conter uma definição como esta (veja Definindo pacotes):

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

Com o arquivo acima, você pode entrar em um ambiente de desenvolvimento para o GDB executando:

guix shell -D -f gdb-devel.scm

--manifest=arquivo

-m arquivo

Crie um ambiente para os pacotes contidos no objeto manifest retornado pelo código Scheme em arquivo. Esta opção pode ser repetida várias vezes, nesse caso os manifestos são concatenados.

Isso é semelhante à opção de mesmo nome em guix package (veja --manifest) e usa os mesmos arquivos de manifesto.

Veja Escrevendo manifestos, para informações sobre como escrever um manifesto. Veja --export-manifest abaixo sobre como obter um primeiro manifesto.

--export-manifest

Grave na saída padrão um manifesto adequado para --manifest correspondente às opções de linha de comando fornecidas.

Esta é uma maneira de “converter” argumentos de linha de comando em um manifesto. Por exemplo, imagine que você está cansado de digitar linhas longas e gostaria de obter um manifesto equivalente a esta linha de comando:

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

Basta adicionar --export-manifest à linha de comando acima:

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

Você pode armazená-lo em um arquivo, digamos manifest.scm, e de lá passá-lo para guix shell ou praticamente qualquer comando guix:

guix shell -m manifest.scm

Voilà, você converteu uma longa linha de comando em um manifesto! Esse processo de conversão honra opções de transformação de pacote (veja Opções de transformação de pacote), então deve ser sem perdas.

--profile=perfil

-p perfil

Crie um ambiente contendo os pacotes instalados em perfil. Use guix package (veja Invocando guix package) para criar e gerenciar perfis.

--pure

Desconfigura variáveis de ambiente existentes ao construir o novo ambiente, exceto aquelas especificadas com --preserve (veja abaixo). Isso tem o efeito de criar um ambiente no qual os caminhos de pesquisa contêm apenas entradas de pacote.

--preserve=regexp

-E regexp

Quando usado junto com --pure, preserva as variáveis de ambiente que correspondem a regexp—em outras palavras, coloca-as em uma “lista branca” de variáveis de ambiente que devem ser preservadas. Esta opção pode ser repetida várias vezes.

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

Este exemplo executa mpirun em um contexto onde as únicas variáveis de ambiente definidas são PATH, variáveis de ambiente cujo nome começa com ‘SLURM’, bem como as variáveis “preciosas” usuais (HOME, USER, etc.).

--search-paths

Exiba as definições de variáveis de ambiente que compõem o ambiente.

--system=sistema

-s sistema

Tente construir para sistema—por exemplo, i686-linux.

--container ¶

-C

Execute comando dentro de um contêiner isolado. O diretório de trabalho atual fora do contêiner é mapeado dentro do contêiner. Além disso, a menos que substituído por --user, um diretório pessoal (home) fictício é criado que corresponde ao diretório pessoal do usuário atual, e /etc/passwd é configurado adequadamente.

O processo gerado é executado como o usuário atual fora do contêiner. Dentro do contêiner, ele tem o mesmo UID e GID que o usuário atual, a menos que --user seja passado (veja abaixo).

--network

-N

Para contêineres, compartilhe o namespace de rede com o sistema host. Os contêineres criados sem esse sinalizador têm acesso somente ao dispositivo de loopback.

--link-profile

-P

Para contêineres, vincule o perfil do ambiente a ~/.guix-profile dentro do contêiner e defina GUIX_ENVIRONMENT para isso. Isso é equivalente a tornar ~/.guix-profile uma ligação simbólica para o perfil real dentro do contêiner. A vinculação falhará e abortará o ambiente se o diretório já existir, o que certamente será o caso se guix shell foi invocado no diretório pessoal do usuário.

Certos pacotes são configurados para procurar em ~/.guix-profile por arquivos de configuração e dados;¹⁵ --link-profile permite que esses programas se comportem conforme o esperado no ambiente.

--user=usuário

-u usuário

Para contêineres, use o nome de usuário usuário no lugar do usuário atual. A entrada /etc/passwd gerada dentro do contêiner conterá o nome usuário, o diretório pessoal será /home/usuário e nenhum dado GECOS do usuário será copiado. Além disso, o UID e o GID dentro do contêiner são 1000. usuário não precisa existir no sistema.

Além disso, qualquer caminho compartilhado ou exposto (veja --share e --expose respectivamente) cujo destino esteja dentro do pessoal do usuário atual será remapeado em relação a /home/USUÁRIO; isso inclui o mapeamento automático do diretório de trabalho atual.

# 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

Embora isso limite o vazamento da identidade do usuário por meio de caminhos iniciais e de cada um dos campos do usuário, esse é apenas um componente útil de uma solução mais ampla de privacidade/anonimato — não uma solução em si.

--no-cwd

Para contêineres, o comportamento padrão é compartilhar o diretório de trabalho atual com o contêiner isolado e mudar imediatamente para esse diretório dentro do contêiner. Se isso for indesejável, --no-cwd fará com que o diretório de trabalho atual não seja compartilhado automaticamente e mudará para o diretório pessoal do usuário dentro do contêiner. Veja também --user.

--expose=fonte[=alvo]

--share=fonte[=alvo]

Para contêineres, --expose (resp. --share) expõe o sistema de arquivos fonte do sistema host como o sistema de arquivos somente leitura (resp. gravável) alvo dentro do contêiner. Se alvo não for especificado, fonte será usado como o ponto de montagem de destino no contêiner.

O exemplo abaixo gera um Guile REPL em um contêiner no qual o diretório pessoal do usuário é acessível somente para leitura por meio do diretório /exchange:

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

--symlink=spec

-S spec

Para contêineres, crie as ligações simbólicas especificadas por spec, conforme documentado em pack-symlink-option.

--emulate-fhs

-F

Quando usado com --container, emule uma configuração do FHS) dentro do contêiner, fornecendo /bin, /lib e outros diretórios e arquivos especificados pelo FHS.

Como Guix desvia da especificação FHS, esta opção configura o contêiner para imitar mais de perto o de outras distribuições GNU/Linux. Isto é útil para reproduzir outros ambientes de desenvolvimento, testar e usar programas que esperam que a especificação FHS seja seguida. Com esta opção, o contêiner incluirá uma versão do glibc que lerá /etc/ld.so.cache dentro do contêiner para o cache da biblioteca compartilhada (ao contrário do glibc no uso regular do Guix) e configurará os diretórios FHS esperados: /bin, /etc, /lib e /usr do perfil do contêiner.

--nesting

-W

Quando usado com --container, forneça Guix dentro do contêiner e organize para que ele possa interagir com o daemon de construção que roda fora do contêiner. Isso é útil se você quiser, dentro do seu contêiner isolado, criar outros contêineres, como nesta sessão de exemplo:

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

A sessão acima inicia um contêiner com programas coreutils disponíveis em PATH. A partir daí, geramos guix shell para criar um contêiner aninhado que fornece nada além de Guile.

Outro exemplo é avaliar um arquivo guix.scm que não é confiável, conforme mostrado aqui:

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

O comando guix build executado acima só pode acessar o diretório atual.

Nos bastidores, a opção -W faz várias coisas:

• mapeia o socket do daemon (por padrão, /var/guix/daemon-socket/socket) dentro do contêiner;
• mapeia todo o armazém (por padrão /gnu/store) dentro do contêiner de forma que os itens do armazém disponibilizados por invocações aninhadas guix sejam visíveis;
• adiciona o comando guix usado atualmente ao perfil no contêiner, de modo que guix describe retorne o mesmo estado dentro e fora do contêiner;
• compartilha o cache (por padrão ~/.cache/guix) com o host, para acelerar operações como guix time-machine e guix shell.

--rebuild-cache ¶

Na maioria dos casos, guix shell armazena em cache o ambiente para que os usos subsequentes sejam instantâneos. As entradas de cache menos usadas recentemente são removidas periodicamente. O cache também é invalidado, ao usar --file ou --manifest, sempre que o arquivo correspondente for modificado.

O --rebuild-cache força o ambiente em cache a ser atualizado. Isso é útil ao usar --file ou --manifest e o arquivo guix.scm ou manifest.scm tem dependências externas, ou se seu comportamento depende, digamos, de variáveis de ambiente.

--root=arquivo ¶

-r arquivo

Crie arquivo como uma ligação simbólica para o perfil deste ambiente e registre-a como raiz do coletor de lixo.

Isso é útil se você deseja proteger seu ambiente da coleta de lixo, para torná-lo “persistente”.

Quando esta opção é omitida, guix shell armazena em cache os perfis para que os usos subsequentes do mesmo ambiente sejam instantâneos — isso é comparável ao uso de --root, exceto que guix shell cuida da remoção periódica das raízes do coletor de lixo menos usadas recentemente.

Em alguns casos, guix shell não armazena perfis em cache—por exemplo, se opções de transformação como --with-latest forem usadas. Nesses casos, o ambiente é protegido da coleta de lixo somente durante a sessão guix shell. Isso significa que na próxima vez que você recriar o mesmo ambiente, poderá ter que reconstruir ou baixar novamente os pacotes.

Veja Invocando guix pack, para mais sobre as raízes do coletor de lixo.

guix shell também suporta todas as opções de compilação comuns que guix build suporta (veja Opções de compilação comuns), bem como opções de transformação de pacotes (veja Opções de transformação de pacote).

7.2 Invocando guix environment

O objetivo do guix environment é auxiliar na criação de ambientes de desenvolvimento.

Aviso de descontinuação: O comando guix environment foi descontinuado em favor do guix shell, que executa funções semelhantes, mas é mais conveniente de usar. Veja Invocando guix shell.

Sendo obsoleto, o guix environment está programado para remoção futura, mas o projeto Guix está comprometido em mantê-lo até 1º de maio de 2023. Entre em contato conosco pelo e-mail guix-devel@gnu.org se quiser discutir o assunto.

A sintaxe geral é:

guix environment opções pacote…

O exemplo a seguir gera uma nova configuração de shell para o desenvolvimento do GNU Guile:

guix environment guile

Se as dependências necessárias ainda não foram construídas, guix environment as constrói automaticamente. O ambiente do novo shell é uma versão aumentada do ambiente em que guix environment foi executado. Ele contém os caminhos de pesquisa necessários para construir o pacote fornecido adicionado às variáveis de ambiente existentes. Para criar um ambiente “puro”, no qual as variáveis de ambiente originais foram desconfiguradas, use a opção --pure¹⁶.

Sair de um ambiente Guix é o mesmo que sair do shell, e colocará o usuário de volta no ambiente antigo antes de guix environment ser invocado. A próxima coleta de lixo (veja Invocando guix gc) limpará os pacotes que foram instalados de dentro do ambiente e não são mais usados fora dele.

guix environment define a variável GUIX_ENVIRONMENT no shell que ele gera; seu valor é o nome do arquivo do perfil deste ambiente. Isso permite que os usuários, digamos, definam um prompt específico para ambientes de desenvolvimento em seu .bashrc (veja Bash Startup Files em Manual de referência do GNU Bash):

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

... ou para navegar pelo perfil:

$ ls "$GUIX_ENVIRONMENT/bin"

Além disso, mais de um pacote pode ser especificado, em cujo caso a união das entradas para os pacotes fornecidos é usada. Por exemplo, o comando abaixo gera um shell onde todas as dependências do Guile e do Emacs estão disponíveis:

guix environment guile emacs

Às vezes, uma sessão de shell interativa não é desejada. Um comando arbitrário pode ser invocado colocando o token -- para separar o comando do resto dos argumentos:

guix environment guile -- make -j4

Em outras situações, é mais conveniente especificar a lista de pacotes necessários no ambiente. Por exemplo, o comando a seguir executa python de um ambiente contendo Python 3 e NumPy:

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

Além disso, pode-se querer as dependências de um pacote e também alguns pacotes adicionais que não são dependências de tempo de construção ou tempo de execução, mas são úteis ao desenvolver, no entanto. Por causa disso, o sinalizador --ad-hoc é posicional. Pacotes que aparecem antes de --ad-hoc são interpretados como pacotes cujas dependências serão adicionadas ao ambiente. Pacotes que aparecem depois são interpretados como pacotes que serão adicionados ao ambiente diretamente. Por exemplo, o comando a seguir cria um ambiente de desenvolvimento Guix que inclui adicionalmente Git e strace:

guix environment --pure guix --ad-hoc git strace

Às vezes, é desejável isolar o ambiente o máximo possível, para máxima pureza e reprodutibilidade. Em particular, ao usar Guix em uma distribuição host que não seja Guix System, é desejável impedir o acesso a /usr/bin e outros recursos de todo o sistema do ambiente de desenvolvimento. Por exemplo, o comando a seguir gera um Guile REPL em um “contêiner” onde apenas o armazém e o diretório de trabalho atual são montados:

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

Nota: A opção --container requer Linux-libre 3.19 ou mais recente.

Outro caso de uso típico para contêineres é executar aplicativos sensíveis à segurança, como um navegador da web. Para executar o Eolie, precisamos expor e compartilhar alguns arquivos e diretórios; incluímos nss-certs e expomos /etc/ssl/certs/ para autenticação HTTPS; finalmente, preservamos a variável de ambiente DISPLAY, pois os aplicativos gráficos em contêiner não serão exibidos sem ela.

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

As opções disponíveis estão resumidas abaixo.

--check

Configure o ambiente e verifique se o shell sobrecarregaria as variáveis de ambiente. Veja --check, para mais informações.

--root=arquivo ¶

-r arquivo

Crie arquivo como uma ligação simbólica para o perfil deste ambiente e registre-a como raiz do coletor de lixo.

Isso é útil se você deseja proteger seu ambiente da coleta de lixo, para torná-lo “persistente”.

Quando esta opção pe omitida, o ambiente é protegido da coleta de lixo apenas pela duração da sessão do guix environment. Isso significa que na próxima vez que você recriar o mesmo ambiente, você tpoderia ter que reconstruir ou refazer o download dos pacotes. Veja Invocando guix gc, para mais sobre GC roots.

--expression=expr

-e expr

Crie um ambiente para o pacote ou lista de pacotes que expr avalia.

Por exemplo, executando:

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

inicia um shell com o ambiente para esta variante específica do pacote PETSc.

Rodando:

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

inicia um shell com todos os pacotes do sistema base disponíveis.

Os comandos acima usam apenas a saída padrão dos pacotes fornecidos. Para selecionar outras saídas, duas tuplas de elementos podem ser especificadas:

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=arquivo

-l arquivo

Crie um ambiente para o pacote ou lista de pacotes que o código dentro de arquivo avalia.

Por exemplo, arquivo pode conter uma definição como esta (veja Definindo pacotes):

(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=arquivo

-m arquivo

Crie um ambiente para os pacotes contidos no objeto manifest retornado pelo código Scheme em arquivo. Esta opção pode ser repetida várias vezes, nesse caso os manifestos são concatenados.

Isso é semelhante à opção de mesmo nome em guix package (veja --manifest) e usa os mesmos arquivos de manifesto.

Veja guix shell --export-manifest, para obter informações sobre como “converter” opções de linha de comando em um manifesto.

--ad-hoc

Inclui todos os pacotes especificados no ambiente resultante, como se um pacote ad hoc fosse definido com eles como entradas. Esta opção é útil para criar rapidamente um ambiente sem ter que escrever uma expressão de pacote para conter as entradas desejadas.

Por exemplo, o comando:

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

executa guile em um ambiente onde Guile e Guile-SDL estão disponíveis.

Observe que este exemplo solicita implicitamente a saída padrão de guile e guile-sdl, mas é possível solicitar uma saída específica — por exemplo, glib:bin solicita a saída bin de glib (veja Pacotes com múltiplas saídas).

Esta opção pode ser composta com o comportamento padrão de guix environment. Pacotes que aparecem antes de --ad-hoc são interpretados como pacotes cujas dependências serão adicionadas ao ambiente, o comportamento padrão. Pacotes que aparecem depois são interpretados como pacotes que serão adicionados ao ambiente diretamente.

--profile=perfil

-p perfil

Crie um ambiente contendo os pacotes instalados em perfil. Use guix package (veja Invocando guix package) para criar e gerenciar perfis.

--pure

Desconfigura variáveis de ambiente existentes ao construir o novo ambiente, exceto aquelas especificadas com --preserve (veja abaixo). Isso tem o efeito de criar um ambiente no qual os caminhos de pesquisa contêm apenas entradas de pacote.

--preserve=regexp

-E regexp

Quando usado junto com --pure, preserva as variáveis de ambiente que correspondem a regexp—em outras palavras, coloca-as em uma “lista branca” de variáveis de ambiente que devem ser preservadas. Esta opção pode ser repetida várias vezes.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

Este exemplo executa mpirun em um contexto onde as únicas variáveis de ambiente definidas são PATH, variáveis de ambiente cujo nome começa com ‘SLURM’, bem como as variáveis “preciosas” usuais (HOME, USER, etc.).

--search-paths

Exiba as definições de variáveis de ambiente que compõem o ambiente.

--system=sistema

-s sistema

Tente construir para sistema—por exemplo, i686-linux.

--container ¶

-C

Execute comando dentro de um contêiner isolado. O diretório de trabalho atual fora do contêiner é mapeado dentro do contêiner. Além disso, a menos que substituído por --user, um diretório pessoal (home) fictício é criado que corresponde ao diretório pessoal do usuário atual, e /etc/passwd é configurado adequadamente.

O processo gerado é executado como o usuário atual fora do contêiner. Dentro do contêiner, ele tem o mesmo UID e GID que o usuário atual, a menos que --user seja passado (veja abaixo).

--network

-N

Para contêineres, compartilhe o namespace de rede com o sistema host. Os contêineres criados sem esse sinalizador têm acesso somente ao dispositivo de loopback.

--link-profile

-P

Para contêineres, vincule o perfil do ambiente a ~/.guix-profile dentro do contêiner e defina GUIX_ENVIRONMENT para isso. Isso é equivalente a tornar ~/.guix-profile uma ligação simbólica para o perfil real dentro do contêiner. A vinculação falhará e abortará o ambiente se o diretório já existir, o que certamente será o caso se guix environment foi invocado no diretório pessoal do usuário.

Certos pacotes são configurados para procurar em ~/.guix-profile por arquivos de configuração e dados;¹⁷ --link-profile permite que esses programas se comportem conforme o esperado no ambiente.

--user=usuário

-u usuário

Para contêineres, use o nome de usuário usuário no lugar do usuário atual. A entrada /etc/passwd gerada dentro do contêiner conterá o nome usuário, o diretório pessoal será /home/usuário e nenhum dado GECOS do usuário será copiado. Além disso, o UID e o GID dentro do contêiner são 1000. usuário não precisa existir no sistema.

Além disso, qualquer caminho compartilhado ou exposto (veja --share e --expose respectivamente) cujo destino esteja dentro do pessoal do usuário atual será remapeado em relação a /home/USUÁRIO; isso inclui o mapeamento automático do diretório de trabalho atual.

# 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

Embora isso limite o vazamento da identidade do usuário por meio de caminhos iniciais e de cada um dos campos do usuário, esse é apenas um componente útil de uma solução mais ampla de privacidade/anonimato — não uma solução em si.

--no-cwd

Para contêineres, o comportamento padrão é compartilhar o diretório de trabalho atual com o contêiner isolado e mudar imediatamente para esse diretório dentro do contêiner. Se isso for indesejável, --no-cwd fará com que o diretório de trabalho atual não seja compartilhado automaticamente e mudará para o diretório pessoal do usuário dentro do contêiner. Veja também --user.

--expose=fonte[=alvo]

--share=fonte[=alvo]

Para contêineres, --expose (resp. --share) expõe o sistema de arquivos fonte do sistema host como o sistema de arquivos somente leitura (resp. gravável) alvo dentro do contêiner. Se alvo não for especificado, fonte será usado como o ponto de montagem de destino no contêiner.

O exemplo abaixo gera um Guile REPL em um contêiner no qual o diretório pessoal do usuário é acessível somente para leitura por meio do diretório /exchange:

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

--emulate-fhs

-F

Para contêineres, emule uma configuração Filesystem Hierarchy Standard (FHS) dentro do contêiner, veja a especificação oficial. Como o Guix se desvia da especificação FHS, esta opção configura o contêiner para imitar mais de perto o de outras distribuições GNU/Linux. Isto é útil para reproduzir outros ambientes de desenvolvimento, testar e usar programas que esperam que a especificação FHS seja seguida. Com esta opção, o contêiner incluirá uma versão de glibc que lerá /etc/ld.so.cache dentro do contêiner para o cache da biblioteca compartilhada (ao contrário de glibc no uso regular do Guix) e configurará os diretórios FHS esperados: /bin, /etc, /lib e /usr do perfil do contêiner.

guix environment também oferece suporte a todas as opções de compilação comuns que guix build oferece suporte (veja Opções de compilação comuns), bem como opções de transformação de pacotes (veja Opções de transformação de pacote).

7.3 Invocando guix pack

Ocasionalmente você quer passar software para pessoas que não têm (ainda!) a sorte de usar Guix. Você diria para elas executarem guix package -i algo, mas isso não é possível neste caso. É aqui que guix pack entra.

Nota: Se você estiver procurando maneiras de trocar binários entre máquinas que já executam Guix, veja Invocando guix copy, Invocando guix publish e Invocando guix archive.

O comando guix pack cria uma embalagem de software encapsulado: ele cria um tarball ou algum outro arquivo contendo os binários do software em que você está interessado e todas as suas dependências. O arquivo resultante pode ser usado em qualquer máquina que não tenha Guix, e as pessoas podem executar exatamente os mesmos binários que você tem com Guix. A embalagem em si é criada de forma reproduzível em bits, para que qualquer um possa verificar se ela realmente contém os resultados da compilação que você pretende enviar.

Por exemplo, para criar uma embalagem contenda Guile, Emacs, Geiser e todas as suas dependências, você pode executar:

$ guix pack guile emacs emacs-geiser
…
/gnu/store/…-pack.tar.gz

O resultado aqui é um tarball contendo um diretório /gnu/store com todos os pacotes relevantes. O tarball resultante contém um perfil com os três pacotes de interesse; o perfil é o mesmo que seria criado por guix package -i. É esse mecanismo que é usado para criar o próprio tarball binário autônomo do Guix (veja Instalação de binários).

Usuários desta embalagem teriam que executar /gnu/store/…-profile/bin/guile para executar o Guile, o que você pode achar inconveniente. Para contornar isso, você pode criar, digamos, uma ligação simbólica /opt/gnu/bin para o perfil:

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

Dessa forma, os usuários podem digitar /opt/gnu/bin/guile e aproveitar.

E se o destinatário do sua embalagem não tiver privilégios de root na máquina dele e, portanto, não puder descompactá-lo no sistema de arquivos raiz? Nesse caso, você vai querer usar a opção --relocatable (veja abaixo). Essa opção produz binários relocáveis, o que significa que eles podem ser colocados em qualquer lugar na hierarquia do sistema de arquivos: no exemplo acima, os usuários podem descompactar seu tarball no diretório pessoal deles e executar diretamente ./opt/gnu/bin/guile.

Como alternativa, você pode produzir uma embalagem no formato de imagem do Docker usando o seguinte comando:

guix pack -f docker -S /bin=bin guile guile-readline

O resultado é um tarball que pode ser passado para o comando docker load, seguido por docker run:

docker load < arquivo
docker run -ti guile-guile-readline /bin/guile

onde arquivo é a imagem retornada por guix pack, e guile-guile-readline é sua “image tag”. Veja documentação do Docker para mais informações.

Outra opção é produzir uma imagem SquashFS com o seguinte comando:

guix pack -f squashfs bash guile emacs emacs-geiser

O resultado é uma imagem do sistema de arquivos SquashFS que pode ser montada ou usada diretamente como uma imagem de contêiner do sistema de arquivos com o ambiente de execução do contêiner Singularity, usando comandos como singularity shell ou singularity exec.

Outro formato internamente baseado em SquashFS é o AppImage. Um arquivo de AppImage pode ser criado e executado sem qualquer provilégio especial:

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

Várias opções de linha de comando permitem que você personalize sua embalagem:

--format=formato

-f formato

Produza uma embalagem no formato fornecido.

Os formatos disponíveis são:

tarball

Este é o formato padrão. Ele produz um tarball contendo todos os binários e ligações simbólicas especificados.

docker

Isso produz um tarball que segue o Docker Image Specification. Por padrão, o “nome do repositório” como aparece na saída do comando docker images é computado a partir de nomes de pacotes passados na linha de comando ou no arquivo manifesto. Como alternativa, o “nome do repositório” também pode ser configurado por meio da opção --image-tag. Consulte --help-docker-format para obter mais informações sobre essas opções avançadas.

squashfs

Isso produz uma imagem SquashFS contendo todos os binários e ligações simbólicas especificados, bem como pontos de montagem vazios para sistemas de arquivos virtuais como procfs.

Nota: Singularity requer que você forneça /bin/sh na imagem. Por esse motivo, guix pack -f squashfs sempre implica -S /bin=bin. Portanto, sua invocação guix pack deve sempre começar com algo como:

guix pack -f squashfs bash …

Se você esquecer o pacote bash (ou similar), singularity run e singularity exec falharão com uma mensagem inútil “nenhum arquivo ou diretório”.

deb ¶

Isso produz um arquivo Debian (um pacote com a extensão de arquivo ‘.deb’) contendo todos os binários e ligações simbólicas especificados, que podem ser instalados em cima de qualquer distribuição GNU(/Linux) baseada em dpkg. Opções avançadas podem ser reveladas por meio da opção --help-deb-format. Elas permitem incorporar arquivos de controle para um controle mais refinado, como ativar gatilhos específicos ou fornecer um script de configuração do mantenedor para executar código de configuração arbitrário na instalação.

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

Nota: Como os arquivos produzidos com guix pack contêm uma coleção de itens de armazém e como cada pacote dpkg não deve ter arquivos conflitantes, na prática isso significa que você provavelmente não conseguirá instalar mais de um desses arquivos em um dado sistema. Você pode, no entanto, empacotar quantos pacotes Guix quiser em um desses arquivos.

Aviso: dpkg assumirá a propriedade de quaisquer arquivos contidos no pacote que ele não saiba. Não é sensato instalar arquivos ‘.deb’ produzidos pelo Guix em um sistema onde /gnu/store é compartilhado por outro software, como uma instalação do Guix ou outras embalagens não deb.

rpm ¶

Isso produz um arquivo RPM (um pacote com a extensão de arquivo ‘.rpm’) contendo todos os binários e ligações simbólicas especificados, que podem ser instalados em cima de qualquer distribuição GNU/Linux baseada em RPM. O formato RPM incorpora somas de verificação para cada arquivo que ele contém, que o comando rpm usa para validar a integridade do arquivo.

Opções avançadas relacionadas a RPM são reveladas por meio da opção --help-rpm-format. Essas opções permitem incorporar scripts de mantenedor que podem ser executados antes ou depois da instalação do arquivo RPM, por exemplo.

O formato RPM suporta pacotes relocáveis por meio da opção --prefix do comando rpm, o que pode ser útil para instalar um pacote RPM em um prefixo específico.

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

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

Nota: Ao contrário dos pacotes Debian, arquivos conflitantes, mas idênticos em pacotes RPM podem ser instalados simultaneamente, o que significa que vários pacotes RPM produzidos pelo guix pack geralmente podem ser instalados lado a lado sem nenhum problema.

Aviso: rpm assume a propriedade de quaisquer arquivos contidos no pacote, o que significa que ele removerá /gnu/store ao desinstalar um pacote RPM gerado pelo Guix, a menos que o pacote RPM tenha sido instalado com a opção --prefix do comando rpm. Não é sensato instalar pacotes ‘.rpm’ produzidos pelo Guix em um sistema onde /gnu/store é compartilhado por outro software, como uma instalação do Guix ou outras embalagens não rpm.

appimage ¶

Isto produz um arquivo AppImage com a extensão ‘.AppImage’. Um AppImage é um volume SquashFS prefixado com uma execução que monta o sistema de arquivo SquashFS e executa o binário criado com o --entry-point. Isso resulta num arquivo auto-contido que agrupa o software e todos os requisitos num único arquivo. Quando o mesmo é executado, ele roda o software empacotado.

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

A execução usada pelos AppImages invoca o comando fusermount3 para montar a imagem rapidamente. Se o comando está indiponível, o AppImage falha em executar, mas ele ainda pode ser iniciado com a opção --appimage-extract-and-run.

Aviso: Ao construir um AppImage, sempre passe a opção --relocatable (ou -R, ou a -RR) para ter certeza que a imagem pode ser usada em sistemas onde o Guix não está instalado. Um aviso é impresso quando esta opção não é usada.

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

Nota: 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.

Nota: 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

Produza binários relocáveis—ou seja, binários que podem ser colocados em qualquer lugar na hierarquia do sistema de arquivos e executados a partir daí.

Quando essa opção é passada uma vez, os binários resultantes requerem suporte para user namespaces no kernel Linux; quando passada duas vezes¹⁸, binários relocáveis recorrem a outras técnicas se os namespaces de usuário não estiverem disponíveis, e essencialmente funcionam em qualquer lugar—veja abaixo as implicações.

Por exemplo, se você criar uma embalagem contendo Bash com:

guix pack -RR -S /mybin=bin bash

... você pode copiar essa embalagem para uma máquina que não tenha Guix e, a partir do seu diretório pessoal, como um usuário normal, executar:

tar xf pack.tar.gz
./mybin/sh

Nesse shell, se você digitar ls /gnu/store, você notará que /gnu/store aparece e contém todas as dependências de bash, mesmo que a máquina realmente não tenha /gnu/store completamente! Essa é provavelmente a maneira mais simples de implementar software construído pelo Guix em uma máquina não Guix.

Nota: Por padrão, binários relocáveis dependem do recurso user namespace do kernel Linux, que permite que usuários sem privilégios montem ou alterem a raiz (chroot). Versões antigas do Linux não o suportavam, e algumas distribuições GNU/Linux o desativam.

Para produzir binários relocáveis que funcionam mesmo na ausência de namespaces de usuário, passe --relocatable ou -R duas vezes. Nesse caso, os binários tentarão o suporte a namespaces de usuário e retornarão a outro mecanismo de execução se os namespaces de usuário não forem suportados. Os seguintes mecanismos de execução são suportados:

default

Experimente usar namespaces de usuário e retorne ao PRoot se eles não forem suportados (veja abaixo).

performance

Experimente usar namespaces de usuário e retorne ao Fakechroot se eles não forem suportados (veja abaixo).

userns

Execute o programa por meio de namespaces de usuário e aborte se eles não forem suportados.

proot

Execute através do PRoot. O programa PRoot fornece o suporte necessário para virtualização do sistema de arquivos. Ele consegue isso usando a chamada de sistema ptrace no programa em execução. Essa abordagem tem a vantagem de funcionar sem exigir suporte especial do kernel, mas incorre em sobrecarga de tempo de execução toda vez que uma chamada de sistema é feita.

fakechroot

Execute através do Fakechroot. Fakechroot virtualiza acessos ao sistema de arquivos interceptando chamadas para funções da biblioteca C, como open, stat, exec e assim por diante. Ao contrário do PRoot, ele incorre em muito pouca sobrecarga. No entanto, nem sempre funciona: por exemplo, alguns acessos ao sistema de arquivos feitos de dentro da biblioteca C não são interceptados, e acessos ao sistema de arquivos feitos via syscalls diretas também não são interceptados, levando a um comportamento errático.

Ao executar um programa encapsulado, você pode solicitar explicitamente um dos mecanismos de execução listados acima, definindo a variável de ambiente GUIX_EXECUTION_ENGINE adequadamente.

--entry-point=comando

Use comando como o ponto de entrada da embalagem resultante, se o formato da embalagem for compatível — atualmente, docker, appimage e squashfs (Singularity) o são. comando deve ser relativo ao perfil contido na embalagem.

O ponto de entrada especifica o comando que ferramentas como docker run ou singularity run iniciam automaticamente por padrão. Por exemplo, você pode fazer:

guix pack -f docker --entry-point=bin/guile guile

A embalagem resultante pode ser facilmente carregado e docker run sem argumentos extras irá gerar bin/guile:

docker load -i pack.tar.gz
docker run image-id

--entry-point-argument=comando

-A comando

Use comando como um argumento para o ponto de entrada da embalagem resultante. Esta opção é válida somente em conjunto com --entry-point e pode aparecer várias vezes na linha de comando.

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

--max-layers=n

Especifica o número máximo de camadas de imagem do Docker permitidas ao criar uma imagem.

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

Esta opção permite que você limite o número de camadas em uma imagem Docker. As imagens Docker são compostas de várias camadas, e cada camada adiciona ao tamanho geral e à complexidade da imagem. Ao definir um número máximo de camadas, você pode controlar os seguintes efeitos:

• Uso do disco: Aumentar o número de camadas pode ajudar a otimizar o espaço em disco necessário para armazenar várias imagens criadas com um grafo de pacote semelhante.
• Puxar: Ao transferir imagens entre diferentes nós ou sistemas, ter mais camadas pode reduzir o tempo necessário para puxar a imagem.

--expression=expr

-e expr

Considere o pacote que expr avalia.

Isso tem o mesmo propósito que a opção de mesmo nome em guix build (veja --expression em guix build).

--file=arquivo

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 (veja --file in guix build), but it has no shorthand, because -f already means --format.

--manifest=arquivo

-m arquivo

Use os pacotes contidos no objeto manifesto retornado pelo código Scheme em arquivo. Esta opção pode ser repetida várias vezes, nesse caso os manifestos são concatenados.

Isto tem um propósito similar à opção de mesmo nome em guix package (veja --manifest) e usa os mesmos arquivos de manifesto. Ele permite que você defina uma coleção de pacotes uma vez e use-a tanto para criar perfis quanto para criar arquivos para uso em máquinas que não tenham o Guix instalado. Note que você pode especificar ou um arquivo de manifesto ou uma lista de pacotes, mas não ambos.

Veja Escrevendo manifestos, para obter informações sobre como escrever um manifesto. Veja guix shell --export-manifest, para obter informações sobre como “converter” opções de linha de comando em um manifesto.

--system=sistema

-s sistema

Tente compilar para sistema—por exemplo, i686-linux—em vez do tipo de sistema do host de compilação.

--target=tripleto ¶

Construção cruzada para tripleto, que deve ser um tripleto GNU válido, como "aarch64-linux-gnu" (veja (Autoconf)autoconf).

--compression=ferramenta

-C ferramenta

Compacte o tarball resultante usando ferramenta—um dos seguintes: gzip, zstd, bzip2, xz, lzip ou none para nenhuma compactação.

--symlink=spec

-S spec

Adicione os symlinks especificados por spec à embalagem. Esta opção pode aparecer várias vezes.

spec tem o formato fonte=alvo, onde fonte é a ligação simbólica que será criado e alvo é o destino da ligação simbólica.

Por exemplo, -S /opt/gnu/bin=bin cria uma ligação simbólica /opt/gnu/bin apontanda para o subdiretório bin do perfil.

--save-provenance

Salvar informações de procedência para os pacotes passados na linha de comando. As informações de procedência incluem a URL e o commit dos canais em uso (veja Canais).

As informações de procedência são salvas no arquivo /gnu/store/…-profile/manifest na embalagem, junto com os metadados usuais do pacote — o nome e a versão de cada pacote, suas entradas propagadas e assim por diante. São informações úteis para o destinatário da embalagem, que então sabe como a embalagem foi (supostamente) obtida.

Esta opção não é habilitada por padrão porque, assim como os timestamps, as informações de proveniência não contribuem em nada para o processo de construção. Em outras palavras, há uma infinidade de URLs de canais e IDs de commit que podem levar à mesma embalagem. Gravar esses metadados “silenciosos” na saída, portanto, potencialmente quebra a propriedade de reprodutibilidade bit a bit de origem para binário.

--root=arquivo ¶

-r arquivo

Crie arquivo como uma ligação simbólica para a embalagem resultante e registre-a como uma raiz do coletor de lixo.

--localstatedir

--profile-name=nome

Inclua o “diretório de estado local”, /var/guix, na embalagem resultante, e principalmente o perfil /var/guix/profiles/per-user/root/nome — por padrão, nome é guix-profile, que corresponde a ~root/.guix-profile.

/var/guix contém o banco de dados do armazém (veja O armazém), bem como as raízes do coletor de lixo (veja Invocando guix gc). Fornecê-lo na embalagem significa que o armazém está “completo” e gerenciável pelo Guix; não fornecê-lo na embalagem significa que o armazém está “morto”: itens não podem ser adicionados a ele ou removidos dele após a extração da embalagem.

Um caso de uso para isso é o tarball binário independente do Guix (veja Instalação de binários).

--derivation

-d

Exiba o nome da derivação que constrói a embalagem.

--bootstrap

Use os binários bootstrap para construir a embalagem. Esta opção é útil somente para desenvolvedores do Guix.

Além disso, guix pack suporta todas as opções de compilação comuns (veja Opções de compilação comuns) e todas as opções de transformação de pacote (veja Opções de transformação de pacote).

7.4 A cadeia de ferramentas do GCC

Se você precisa de uma cadeia de ferramentas completa para compilar e vincular código-fonte C ou C++, use o pacote gcc-toolchain. Este pacote fornece uma cadeia de ferramentas GCC completa para desenvolvimento C/C++, incluindo o próprio GCC, a GNU C Library (cabeçalhos e binários, além de símbolos de depuração na saída debug), Binutils e um wrapper de vinculador.

O propósito do wrapper é inspecionar os switches -L e -l passados para o vinculador, adicionar argumentos -rpath correspondentes e invocar o vinculador real com esse novo conjunto de argumentos. Você pode instruir o wrapper a se recusar a vincular bibliotecas que não estejam no store definindo a variável de ambiente GUIX_LD_WRAPPER_ALLOW_IMPURITIES como no.

O pacote gfortran-toolchain fornece uma cadeia de ferramentas GCC completa para desenvolvimento Fortran. Para outras linguagens, use ‘guix search gcc toolchain’ (veja Invoking guix package).

7.5 Invocando guix git authenticate

O comando guix git authenticate autentica um checkout do Git seguindo a mesma regra dos canais (veja autenticação dos canais). Ou seja, a partir de um commit determinado, ele garante que todos os commits subsequentes sejam assinados por uma chave OpenPGP cuja impressão digital apareça no arquivo .guix-authorizations de seus commits pais.

Você achará esse comando útil se mantiver um canal. Mas, na verdade, esse mecanismo de autenticação é útil em um contexto mais amplo, então você pode querer usá-lo para repositórios Git que não tenham nada a ver com Guix.

A sintaxe geral é:

guix git authenticate commit signer [options…]

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 (veja channel introduction). 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 [opções…]

Caso você tenha ramos que exijam introduções diferentes, você pode especificá-las diretamente em .git/config. Por exemplo, se o ramo chamado personal-fork tiver uma introdução diferente de outros ramos, você pode estender .git/config ao longo destas linhas:

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

A primeira execução também tenta instalar ganchos pré-push e pós-mesclagem, de modo que guix git authenticate seja invocado assim que você executar git push, git pull e comandos relacionados; no entanto, ele não substitui ganchos preexistentes.

As opções de linha de comando descritas abaixo permitem que você ajuste o processo.

--repository=diretório

-r diretório

Abra o repositório Git em diretório em vez do diretório atual.

--keyring=referência

-k referência

Carregue o chaveiro OpenPGP de referência, a referência de uma ramificação como origin/keyring ou my-keyring. A ramificação deve conter chaves públicas OpenPGP em arquivos .key, em formato binário ou “ASCII-armored”. Por padrão, o chaveiro é carregado da ramificação chamada keyring.

--end=commit

Autentique revisões até commit.

--stats

Exibir estatísticas de assinatura de confirmação após a conclusão.

--cache-key=chave

Os commits autenticados anteriormente são armazenados em cache em um arquivo em ~/.cache/guix/authentication. Esta opção força o cache a ser armazenado no arquivo chave naquele diretório.

--historical-authorizations=arquivo

Por padrão, qualquer commit cujo(s) commit(s) pai(s) não tenha(m) o arquivo .guix-authorizations é considerado não autêntico. Em contraste, esta opção considera as autorizações em arquivo para qualquer commit que não tenha .guix-authorizations. O formato de arquivo é o mesmo que o de .guix-authorizations (veja formato .guix-authorizations).

8.1 Módulos de pacote

Do ponto de vista da programação, as definições de pacotes da distribuição GNU são fornecidas pelos módulos Guile no namespace (gnu packages …)¹⁹ (veja módulos Guile em Manual de Referência do GNU Guile). Por exemplo, o módulo (gnu packages emacs) exporta uma variável chamada emacs, que é vinculada a um objeto <package> (veja Definindo pacotes).

O namespace do módulo (gnu packages …) é automaticamente escaneado em busca de pacotes pelas ferramentas de linha de comando. Por exemplo, ao executar guix install emacs, todos os módulos (gnu packages …) são escaneados até que um que exporte um objeto de pacote cujo nome é emacs seja encontrado. Esse recurso de busca de pacotes é implementado no módulo (gnu packages).

Os usuários podem armazenar definições de pacotes em módulos com nomes diferentes — por exemplo, (my-packages emacs)²⁰. Há duas maneiras de tornar essas definições de pacotes visíveis para as interfaces do usuário:

1. Ao adicionar o diretório que contém os módulos do seu pacote ao caminho de pesquisa com o sinalizador -L do guix package e outros comandos (veja Opções de compilação comuns), ou definindo a variável de ambiente GUIX_PACKAGE_PATH descrita abaixo.
2. Ao definir um canal e configurando guix pull para que ele puxe dele. Um canal é essencialmente um repositório Git contendo módulos de pacote. Veja Canais, para mais informações sobre como definir e usar canais.

GUIX_PACKAGE_PATH funciona de forma semelhante a outras variáveis de caminho de pesquisa:

Variável de ambiente: GUIX_PACKAGE_PATH

Esta é uma lista de diretórios separados por dois pontos para procurar módulos de pacotes adicionais. Os diretórios listados nesta variável têm precedência sobre os próprios módulos da distribuição.

A distribuição é totalmente bootstrapped e auto-contida: cada pacote é construído com base somente em outros pacotes na distribuição. A raiz deste grafo de dependência é um pequeno conjunto dos binários bootstrap, fornecido pelo módulo (gnu packages bootstrap). Para mais informações sobre bootstrapping, veja Inicializando.

8.2 Definindo pacotes

A interface de alto nível para definições de pacotes é implementada nos módulos (guix packages) e (guix build-system). Como exemplo, a definição de pacote, ou receita, para o pacote GNU Hello se parece com isto:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (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+)))

Sem ser um especialista em Scheme, o leitor pode ter adivinhado o significado dos vários campos aqui. Esta expressão vincula a variável hello a um objeto <package>, que é essencialmente um registro (veja Scheme records em Manual de Referência do GNU Guile). Este objeto de pacote pode ser inspecionado usando procedimentos encontrados no módulo (guix packages); por exemplo, (package-name hello) retorna—surpresa!—"hello".

Com sorte, você poderá importar parte ou toda a definição do pacote de seu interesse de outro repositório, usando o comando guix import (veja Invoking guix import).

No exemplo acima, hello é definido em um módulo próprio, (gnu packages hello). Tecnicamente, isso não é estritamente necessário, mas é conveniente fazê-lo: todos os pacotes definidos em módulos sob (gnu packages …) são automaticamente conhecidos pelas ferramentas de linha de comando (veja Módulos de pacote).

Há alguns pontos que vale a pena observar na definição do pacote acima:

• O campo source do pacote é um objeto <origin> (veja Referência do origin, para a referência completa). Aqui, o método url-fetch de (guix download) é usado, o que significa que a fonte é um arquivo a ser baixado por FTP ou HTTP.

  O prefixo mirror://gnu instrui url-fetch a usar um dos espelhos GNU definidos em (guix download).

  O campo sha256 especifica o hash SHA256 esperado do arquivo que está sendo baixado. É obrigatório e permite que o Guix verifique a integridade do arquivo. O formulário (base32 …) introduz a representação base32 do hash. Você pode obter essas informações com guix download (veja Invocando guix download) e guix hash (veja Invocando guix hash).

  Quando necessário, o formulário origin também pode ter um campo patches listando os remendos a serem aplicados e um campo snippet fornecendo uma expressão Scheme para modificar o código-fonte.

• O campo build-system especifica o procedimento para construir o pacote (veja Sistemas de compilação). Aqui, gnu-build-system representa o familiar GNU Build System, onde os pacotes podem ser configurados, construídos e instalados com a sequência de comando usual ./configure && make && make check && make install.

  Ao começar a empacotar software não trivial, você pode precisar de ferramentas para manipular essas fases de compilação, manipular arquivos e assim por diante. Veja Construir utilitários, para mais informações sobre isso.

• O campo arguments especifica opções para o sistema de compilação (veja Sistemas de compilação). Aqui, ele é interpretado por gnu-build-system como uma solicitação executada configure com o sinalizador --enable-silent-rules.

  E quanto a esses caracteres de citação (')? Eles são sintaxe Scheme para introduzir uma lista literal; ' é sinônimo de quote. Às vezes, você também verá ` (uma crase, sinônimo de quasiquote) e , (uma vírgula, sinônimo de unquote). Veja quoting em Manual de referência do GNU Guile, para detalhes. Aqui, o valor do campo arguments é uma lista de argumentos passados para o sistema de construção mais adiante, como com apply (veja apply em Manual de referência do GNU Guile).

  A sequência hash-dois-pontos (#:) define um palavra-chave em Scheme (veja Keywords em Manual de referência do GNU Guile) e #:configure-flags é uma palavra-chave usada para passar um argumento de palavra-chave para o sistema de compilação (veja Coding With Keywords em Manual de referência do GNU Guile).

• O campo inputs especifica entradas para o processo de construção—i.e., dependências de tempo de construção ou tempo de execução do pacote. Aqui, adicionamos uma entrada, uma referência à variável gawk; gawk é ele próprio vinculado a um objeto <package>.

  Note que GCC, Coreutils, Bash e outras ferramentas essenciais não precisam ser especificadas como entradas aqui. Em vez disso, gnu-build-system cuida de garantir que elas estejam presentes (veja Sistemas de compilação).

  No entanto, quaisquer outras dependências precisam ser especificadas no campo inputs. Qualquer dependência não especificada aqui simplesmente ficará indisponível para o processo de build, possivelmente levando a uma falha de build.

Veja Referência do package, para uma descrição completa dos campos possíveis.

Indo além: Intimidado pela linguagem Scheme ou curioso sobre ela? O Livro de receitas tem uma seção curta para começar que recapitula algumas das coisas mostradas acima e explica os fundamentos. Veja Um curso intensivo de Scheme em Livro de receitas do GNU Guix, para mais informações.

Uma vez que uma definição de pacote esteja pronta, o pacote pode ser realmente construído usando a ferramenta de linha de comando guix build (veja Invocando guix build), solucionando problemas de quaisquer falhas de construção que você encontrar (veja Depurando falhas de compilação). Você pode facilmente voltar para a definição do pacote usando o comando guix edit (veja Invocando guix edit). Veja Diretrizes de empacotamento, para mais informações sobre como testar definições de pacote, e Invocando guix lint, para informações sobre como verificar uma definição para conformidade de estilo. Por fim, veja Canais, para obter informações sobre como estender a distribuição adicionando suas próprias definições de pacote em um “canal”.