Um olhar sobre o Portage-Tools - Parte III

Nesta terceira parte, pretendo introduzir os conceitos de USE flags e sua utilização. Como podemos construir um sistema moderno e estável definindo as flags necessárias. Vou expor também o arquivo de configurações que, talvez, seja o mais conhecido e utilizado no Gentoo: o make.conf. Vou apresentar também outros arquivos de configuração muito úteis para a dupla dinâmica: Portage/Emerge. Vamos nessa!

[ Hits: 12.008 ]

Por: Luiz Santos em 07/07/2016


O arquivo make.conf - PARTE III



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:

CHOST="x86_64-pc-linux-gnu"

Ou ainda:

CHOST="sparc-unknown-linux-gnu"

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

COLLISION_IGNORE="/usr/kde/live/share/icons/oxygen/16x16"

- 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="/usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/"

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

CONFIG_PROTECT_MASK="/etc/gconf"

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

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. USE FLAGS
   3. USE FLAGS - PARTE II
   4. USE FLAGS - PARTE III
   5. O arquivo make.conf
   6. O arquivo make.conf - PARTE II
   7. O arquivo make.conf - PARTE II - variáveis cflags / cxxflags e otimização do sistema
   8. O arquivo make.conf - PARTE III
   9. O arquivo make.conf - PARTE IV
   10. O arquivo make.conf - PARTE V
   11. Finalizando
Outros artigos deste autor

Um olhar sobre o Portage Tools - Parte II

Um olhar sobre o Portage-tools - Parte I

Leitura recomendada

Bind consultando zonas em base LDAP

Ubuntu Minimal para Usuários Comuns

Instalação e configuração do LTSP 5 no Ubuntu 11.04

Criando uma WEBApi utilizando dotnet core e vscode

Shell do GNU/Linux

  
Comentários
[1] Comentário enviado por luiztux em 07/07/2016 - 08:41h

Galera, uma atualização:

Sobre a variável do USE_EXPAND, a L10N, esta irá substituir a variável LINGUAS em um futuro próximo. Então, obrigatoriamente, devemos ter ambas informadas no nosso make.conf respeitando as diferenças de padrões entre elas.

É isso aí.

-----------------------------------''----------------------------------

"If it moves, compile it."


[2] Comentário enviado por albfneto em 07/07/2016 - 12:06h

muito bom isso! parabéns.
favoritado , como as outras partes.
é legal a galera conhecer Portage. Portage é uma obra prima de programação
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[3] Comentário enviado por luiztux em 07/07/2016 - 12:20h


[2] Comentário enviado por albfneto em 07/07/2016 - 12:06h

muito bom isso! parabéns.
favoritado , como as outras partes.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].


Obrigado Alberto. Sua opinião vale muito pois, como escrevi, parte deste conhecimento obtive através de você. Então eu sinto uma relação de supervisão da sua parte, por assim dizer..rsrsr

[4] Comentário enviado por albfneto em 09/07/2016 - 19:53h

quando terminar tudo, vou fazer uma sugestão.
você junta todas as partes, com copiar e colar, e faz uma apostila ou pequeno livro, e posta no Site "Domínio Público". Cite sua autoria, lógicamente.

tem muita coisa de linux lá, de Química, de Artes, de tudo. Pa vc ver, vai no site

http://www.dominiopublico.gov.br/pesquisa/PesquisaObraForm.do

e no formulário de busca use Palavras-Chave "Ciências da Computação", "Linux".

o legal do site Domínio Público é que ele é desenvolvido usando Software Livre

No que se refere a seu Artigo, sugerí porque Portage tem pouca literatura em Português.

Eu gostaria que muita gente conhecesse Portage, porque é fenomenal, muito bem programado. Ele acha as dependências, gerencia tudo, faz o que vc quer... um GCC, mas um GCC todo automático. Portage é genial

Não sei Porque, mas alguns Gentoístas, no Mundo todo, não eu, você ou o próprio Daniel Robbins (ele é muito acessível, sempre respondeu meus emails), não gostam de ensinar a usar Gentoo ou Portage, não sei ao certo o por que.
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[5] Comentário enviado por luiztux em 09/07/2016 - 20:20h

Gostei da ideia e agradeço. Farei isto quando terminar.

Em relação ao Daniel, realmente, o cara é muito acessível e solícito. Também tive a oportunidade de falar com ele e com outros desenvolvedores do Gentoo como: Nathan Zachary, Michal Gorny e Zack Medico e os caras sempre muito solícitos, sem problema nenhum. Mas infelizmente tem aqueles que se acham superiores aos outros e não gostam de ajudar. É uma lástima...


-----------------------------------''----------------------------------

"If it moves, compile it."


[6] Comentário enviado por Pygoscelis em 13/07/2016 - 13:51h

.

[7] Comentário enviado por Pygoscelis em 13/07/2016 - 13:52h

Muito bom e útil! Se tivesse lido esses artigos um tempo atrás, quando migrei para Gentoo, diminuiria bastante minhas leituras e buscas. Legal também reunir links do Alberto que tanto já me foram úteis. Valeu!

[8] Comentário enviado por luiztux em 14/07/2016 - 08:48h


[7] Comentário enviado por Pygoscelis em 13/07/2016 - 13:52h

Muito bom e útil! Se tivesse lido esses artigos um tempo atrás, quando migrei para Gentoo, diminuiria bastante minhas leituras e buscas. Legal também reunir links do Alberto que tanto já me foram úteis. Valeu!


Obrigado pelo comentário. Realmente precisamos de extensiva leitura para usar o Gentoo. Nestes artigos tentei passar um pouco do que aprendi, depois de muita busca e leitura, como você disse. Claro que isto não irá tornar nada mais fácil para quem chega ao sistema, mas espero que dê um "Norte" para quem precisar.
O Alberto é um cara excepcional que manja demais. Os artigos e dicas dele são referência e por este motivo eu reuni estas informações.

Um abraço.

[9] Comentário enviado por removido em 30/07/2016 - 19:16h

Ainda vou instalar o Gentoo, basta eu conseguir algum tempo livre.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts