---

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 home 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 Invoking 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.