Beleza, vamos dar continuidade. A próxima variável é a CHOST.

- CHOST: A variável CHOST informa ao compilador para qual arquitetura compilar os códigos. Ao contrário da variável CFLAGS, que é utilizada para otimização, a configuração do CHOST é fixa e não é alterada facilmente, muito embora possamos fazer esta alteração. Geralmente seus valores são preenchidos automaticamente de acordo com o profile escolhido. O padrão aqui é: ARCH-VENDOR-OS-LIBC (mantive os nomes em inglês por compatibilidade). Examinando em detalhes, temos:

• ARCH: arquitetura da CPU (i686, x86_64);
• VENDOR: especifica a plataforma do hardware ou fornecedor (pc, em alguns casos: unknown, gentoo, hardfloat);
• OS: sistema operacional (linux, gentoo-freebsd9.0, elf);
• LIBC: biblioteca do C em uso (eabi, gnu, uclibc).

O campo relacionado à biblioteca, LIBC, não é suportado no Gentoo/FreeBSD, então este campo deve (e será) omitido. Então os valores aqui, geralmente, serão os seguintes:


Ou ainda:


- CLEAN_DELAY = inteiro: nesta variável determinamos o tempo de espera do comando emerge --unmerge, antes de executar a ação. O padrão é 5 segundos.

- COLLISION_IGNORE: esta variável desabilita as variáveis collision-protect e protect-owned. Ambas serão explicadas mais pra frente. Nesta variável devemos informar os diretórios que o Portage deverá ignorar em caso de colisão de arquivos. Por ex.:


- CONFIG_PROTECT: arquivos ou diretórios listados aqui serão habilitados pela feature config file protection e terão seus arquivos protegidos. O propósito desta feature é prevenir que novos pacotes instalados se sobreponham sobre arquivos já existentes. Por padrão, esta feature está habilitada no diretório /etc.

Quando o Portage instalar um arquivo em um diretório protegido, os arquivos lá contidos não serão sobrescritos. Se o nome de um arquivo já existe, o Portage nomeará o arquivo a ser instalado de, por exemplo, foo para ._cfg0000_foo. Se algum arquivo com este nome já existir, o Portage o nomeará para ._cfg0001_foo.

Podemos gerenciar estes arquivos com as ferramentas dispatch-conf, cfg-update, e etc-update, falarei sobre as mesmas em outro artigo. Exemplo de declaração:


- CONFIG_PROTECT_MASK: todos os arquivos ou diretórios listados aqui, terão a feature config file protection desabilitada. Assim, caso o Portage instale arquivos nestes diretórios, os arquivos já existentes serão sobrescritos. Exemplo de configuração:


- DISTDIR: esta variável define o local onde o Portage alocará os arquivos de códigos fontes baixados. O diretório padrão é /usr/portage/distfiles. É neste diretório que ficam os códigos fonte dos programas instalados ou que serão instalados. Sendo assim é um diretório que tende a crescer exponencialmente, além disto, este diretório não será limpo de forma automática pelo Portage, então os usuários devem sempre gerenciar isto através de ferramentas específicas, como o eclean (que vou falar nos demais artigos desta série).

EMERGE_DEFAULT_OPTS: opções que serão adicionadas ao final de todo comando emerge, todas as vezes que o mesmo for chamado. Caso a opção do emerge --ignore-default-opts for passada antes da compilação, as opções definidas nesta variável serão ignoradas. Não vou comentar sobre todas as opções pois a maioria delas não faz sentido declarar, uma vez que o emerge sempre buscará esta informação.

Assim, imaginemos como seria sempre buscar dependências dinâmicas, informações de debug etc. Ficaria inviável. Além disto, há um grande número de opções que são habilitadas por default e a intenção deste artigo não é ser uma tradução da man page. Então, apresento as opções que acredito serem as mais adequadas para uma configuração global.

Entretanto, todas as opções default do emerge podem ser adicionadas à variável no make.conf. Se estiver curioso, dê uma olhada na man page e defina por conta própria. Vamos nessa:

• --accept-properties: equivale à configuração da variável ACCEPT_PROPERTIES do make.conf;
• --accept-restrict: equivale à configuração da variável ACCEPT_RESTRICT do make.conf;
• --alert [ y | n ]: adiciona o caractere de alerta (/a) para prompts interativos;
• --alphabetical: quando a saída do emerge listar USE flags, ou outras flags, solicitadas pelo usuário, habilitando esta opção fará com que a saída seja ordenada em uma lista em ordem alfabética;
• --ask [ y | n ]: antes de realizar qualquer ação, mostra o que será feito e aguarda confirmação do usuário. Caso seja pressionada a tecla Enter, será interpretado como a primeira escolha (y);
• --ask-enter-invalid: quando usada em conjunto com --ask, interpretará a tecla Enter como entrada inválida, prevenindo aceitações acidentais por parte do usuário;
• --autounmask [ y | n ]: desmascara pacotes de forma automática para satisfazer dependências, gerando o package.use desta dependência. Esta opção é ativada por padrão.

Quando o Portage encontrar um caso em que seja necessário alguma configuração, será mostrado que tipo de configuração, pacotes, arquivos etc., é necessário modificar/criar para que a instalação possa proceder. Com estas informações em mãos, devemos passá-las para os arquivos necessários. Por exemplo:
Assim, uma resolução manual seria o seguinte:

Caso use um único arquivo package.unmask contendo uma informação por linha:

# echo "=x11-base/xorg-server-1.11.99.2" >> /etc/portage/package.unmask

Caso use diretório e um arquivo para cada pacote desmascarado:

# echo "=x11-base/xorg-server-1.11.99.2" > /etc/portage/package.unmask/xorg-server

Entretanto há uma outra opção que veremos daqui a pouco...

--autounmask-unrestricted-atoms [ y | n ]: se a opção acima estiver habilitada, o que está por padrão, escreverá atoms desmascarados com o operador >= sempre que possível. No primeiro artigo sobre Portage-Tools,dei alguns exemplos de atoms, que nada mais são que ebuilds com versões específicas: = (igual), < (menor), > (maior), <= (menor ou igual) e >= (maior ou igual).

--autounmask-keep-masks [ y | n ]: caso a opção --autounmask esteja habilitada, como sabemos que está por padrão, este comando fará com que nenhuma mudança seja feita no package.unmask.

--autounmask-write [ y | n ]: caso a opção --autounmask esteja habilitada, as mudanças necessárias para desmascarar um pacote serão escritas nos respectivos arquivos, respeitando os valores da variável CONFIG_PROTECT e da opção --ask do emerge. Se a mudança necessária tiver que ser feita em um arquivo, esta será adicionada ao final do mesmo. Se for um diretório, será criado um arquivo com o nome do pacote desmascarado. Esta é a outra opção para desmascarar um pacote automaticamente (--autounmask). O procedimento é o seguinte:

Pegando como exemplo o mesmo pacote e o mesmo problema encontrado na opção --autounmask, teríamos que fazer o seguinte:

# emerge --ask --autounmask-write =xorg-server-1.11.99.2
# dispatch-conf

Ou...

# etc-update

O dispatch-conf irá mostrar as diferenças entre os arquivos recém alterados. Verifique as mudanças e aplique-as. Após isto basta rodar novamente:

# emerge --ask =xorg-server-1.11.99.2

Trabalhoso? Sim e não. Geralmente não é uma boa opção desmascarar pacotes pois os mesmos estão neste status por conta de bugs, vulnerabilidades etc., e ainda não foram testados exaustivamente. Com o Gentoo possuímos o poder da escolha. Então fica a critério do usuário fazer modificações ou não.

--color < y | n >: habilita ou desabilita a saída colorizada. Caso seja definida, esta opção fará com que a definição da variável NOCOLOR (que veremos mais pra frente) seja ignorada.

--misspell-suggestions < y | n >: sabe aquela hora em que não sabemos o nome de um pacote e escrevemos metade do nome e o programa te devolve uma lista de sugestões com nomes parecidos? Ou ainda quando há inúmeros programas com nomes parecidos? Pois bem, com esta opção habilitamos ou desabilitamos esta funcionalidade.

--quiet-unmerge-warn: esta opção desabilita a mensagem de aviso que é mostrada antes de executar as ações do comando --unmerge.

--search-index < y | n >: habilita ou desabilita indexação nas buscas para as ações de busca. Por padrão esta opção está ativa.

--select [ y | n ]: adiciona um pacote específico ao arquivo world (explicado na parte I desta série). Mesmo que você tenha instalado o pacote com a opção do emerge --oneshot (ou -1), você poderá adicionar este pacote ao world, por ex.:

# emerge --select y x11-misc/openbox-menu

O comando acima não fará uma nova compilação ;)

Igualmente é possível retirar um pacote do world com o inverso deste comando:

# emerge --oneshot x11-misc/openbox-menu

--with-bdeps < y | n >: nos cálculos de compilação, esta opção busca dependências que não são estritamente necessárias. O padrão para instalação é 'n' indicando que nunca serão instalados (salvo explicitado pelo usuário) e 'y' para as ações de --depclean, indicando que não serão removidas. É por este motivo que quando rodamos o --depclean em todo o sistema ou em apenas um pacote, o Portage sempre mostrará uma mensagem indicando que há dependências no sistema e que é necessário rodar o comando @preserved-rebuild, ou ainda o @module-rebuild. É porque as dependências ainda estão no sistema. Para se livrar disto, retire-as também.