Próximo: Invocando guix package
, Acima: Gerenciamento de pacote [Conteúdo][Índice]
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.
Próximo: Invocando guix package
, Acima: Gerenciamento de pacote [Conteúdo][Índice]