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

Por: Luiz Santos em 07/07/2016 | Blog: https://www.vivaolinux.com.br/~luiztux


O arquivo make.conf - PARTE IV



Continuando com as variáveis do make...

- EMERGE_LOG_DIR: controla o local dos logs: emerge.log e emerge-fetch.log. O default é o diretório /var/log.

- EMERGE_WARNING_DELAY: determina o tempo de duração da mensagem de aviso após o comando emerge --unmerge. O valor default é 10 segundos.

- EPAUSE_IGNORE: define se ignora ou não pausas curtas que ocorrem quando importantes informações são mostradas. Esta variável é desabilitada por default.

- EXTRA_ECONF: nesta variável podemos informar configurações adicionais para a função econf(), presente nos ebuilds, na fase de configuração de um pacote. Ao contrário do que possa parecer esta opção não é para desenvolvedores, mas sim para usuários normais (que saibam o que estão fazendo).

Como o make.conf é um arquivo global, dependendo das informações aqui, os pacotes não serão compilados pois algumas configurações podem ser específicas de determinados pacotes e ainda, esta configuração funcionará apenas com pacotes que utilizem o GNU Autotools. Um bom exemplo para configuração global, poderia ser algo como:

EXTRA_ECONF="--sysconfdir=/etc/diretorio/"

Podemos também informar configurações extras no momento da compilação. Como exemplo, peguemos o econf() do pacote app-portage/eix:

src_configure() {
   econf $(use_with sqlite) $(use_with doc extra-doc)
      $(use_enable nls) $(use_enable tools separate-tools)
      $(use_enable security) $(use_enable optimization)
      $(use_enable strong-security)
      $(use_enable strong-optimization) $(use_enable debug debugging)
      $(use_enable swap-remote)
      $(use_with prefix always-accept-keywords)
      $(use_with dep dep-default)
      --with-zsh-completion
      --with-portage-rootpath="${ROOTPATH}"
      --with-eprefix-default="${EPREFIX}"
}

Assim, teríamos o seguinte:

EXTRA_ECONF="--with-zsh-completion" emerge -av app-portage/eix

Mas, o modo acima valerá apenas para esta compilação. Em caso de atualização ou recompilação, teria que informar tudo de novo. Então como fazer de forma persistente? Assim:

No diretório /etc/portage/env/, crie um arquivo com o nome do pacote. Por exemplo: /etc/portage/env/eix.conf. Dentro deste arquivo coloque o seguinte:

EXTRA_ECONF="--with-zsh-completion"

Salve e saia. Após isto, abra o arquivo em /etc/portage/package.env e adicione, sem apagar quaisquer previas linhas, a seguinte informação:

app-portage/eix eix.conf

Salve e saia. Suas configurações se tornarão persistentes.

-FEATURES: algumas características que o Portage deve tomar por padrão. Muitas delas são para desenvolvedores, então não mostrarei todas, apenas as que forem interessantes para usuários, outras são habilitadas por default, então não vamos prolongar demais. AVISO: não desabilite o sandbox! As features interessantes para usuários podem ser:

binpkg-logs: se você instala pacotes binários via Portage, pode ser interessante manter alguns logs. Defina isto com esta feature. Entretanto esta será relevante apenas se a variável do make.conf, PORT_LOGDIR, estiver definida.

buildpkg: você gosta de pacotes binários então? Coloque isto como feature e o Portage transformará todos os pacotes que você quiser instalar, em binários.

buildsyspkg: falei sobre o arquivo @SET na parte I desta série. Com esta feature, o Portage construirá binários dos pacotes informados neste arquivo.

candy: habilita uma barra de progresso especial do Portage. É bacaninha até...

clean-logs: habilita a execução automática do comando definido na variável do make.conf, PORT_LOGDIR_CLEAN. O que for definido aqui, removerá o o(s) diretório(s) especificado(s) na variável do make.conf, PORT_LOGDIR, que tenham sido modificados à pelo menos 7 dias.

collision-protect: um recurso do projeto de Garantia de Qualidade (QA) do Gentoo, que previne que um pacote não substitua arquivos que não pertencem à ele. A variável do make.conf, COLLISION_IGNORE, pode ser usada para selecionar quais arquivos ignorar, alterando o que for definido nesta feature.

ebuild-locks: bloqueie fases de ebuilds que não estejam dentro de um sandbox para que nunca executem concorrentemente.

fail-clean: recurso para limpar arquivos temporários de compilações malsucedidas. Seu uso é encorajado caso você tenha indicado o PORTAGE_TMPDIR no tmpfs. Se você habilitar isto, habilite também a variável PORT_LOGDIR, para garantir que os logs dos ebuilds sejam salvos.

parallel-fetch: busca em segundo plano enquanto compila. Para ver o status da busca, basta rodar o seguinte comando em outro terminal: tail -f /var/log/emerge-fetch.log.

preserve-libs: preserva bibliotecas sonames quando estes mudarem durante um upgrade ou downgrade.

protect-owned: recurso idêntico ao collision_protect, exceto que os arquivos podem ser substituídos se não forem explicitamente listados no conteúdo de um pacote instalado. Isto é útil em sistemas que tem muitos arquivos órfãos que foram deixados para trás por versões mais antigas do Portage que não suportavam o recurso de unmerge-orphans.

Assim como no recurso collision-protect, a variável COLLISION_IGNORE pode ser usada para desativar seletivamente esta função. É recomendado deixar tanto o recurso protect-owned, quanto o collision-protect habilitados durante todo o tempo, caso contrário, arquivos podem ser substituídos em momentos inapropriados. Se o recurso collision-protect estiver habilitado então ele terá precedência sobre protect-owned.

sandbox¹: habilita o sandbox quando usamos os comandos emerge e ebuild.

unmerge-logs: mantém os logs dos pacotes durante as fases de unmerge. Este recurso será relevante apenas se a variável PORT_LOGDIR estiver definida.

unmerge-orphans: remove pacotes que não pertençam a nenhum pacote instalado no mesmo SLOT e que não esteja protegido pela variável CONFIG_PROTECT.

userfetch: quando o Portage está buscando um pacote, ele faz isto como root e se precisarmos ou quisermos, em outro terminal, instalar outro pacote, teremos que esperar o Portage terminar a busca anterior pois o root estará bloqueado. Este recurso desbloqueia esta busca alterando-a para rodar como usuário.

userpriv: quase o mesmo caso que o de cima, porém este recurso habilita a compilação de pacotes, durante determinadas fases, para usuários non-root.

usersandbox: habilita o uso do sandbox durante a fase de compilação quando estiver rodando sem privilégios de root (via userpriv).

Estes são os recursos que acredito serem úteis para usarmos no geral. Vamos continuar com as variáveis do make.conf.

- FETCHCOMMAND: o Portage, por padrão, utiliza o wget para buscar e baixar o código fonte dos pacotes. Mude isto aqui nesta variável seguindo algumas regras: deve conter o caminho completo do comando assim como os espaços reservados ${DISTDIR}, ${FILE} e ${URI}. Por exemplo, caso utilizemos outro programa, poderíamos fazer assim:

# Lukemftp (BSD ftp):
FETCHCOMMAND="lukemftp -s -a -o "${DISTDIR}/${FILE}" "${URI}""

- GENTOO_MIRRORS: lista com os mirrors que serão usados para baixar os pacotes para compilação. Ex.:

GENTOO_MIRRORS="ftp://ftp.las.ic.unicamp.br/pub/gentoo/
http://www.las.ic.unicamp.br/pub/gentoo/
http://www.linorg.ciagri.usp.br/gentoo/"

- MAKEOPTS: usamos esta variável para permitir a execução de múltiplas sessões do comando make, quando da compilação, de acordo com a quantidade de núcleos da CPU. O truque aqui é o seguinte: nº de CPUs+1. Sendo assim, faça:

MAKEOPTS="-j5" #opção -j de jobs, seguido pelo número de núcleos + 1

NOCOLOR = ["true" | "false"]: define se a saída colorizada deve ser desabilitada. O padrão é false.

NOTA: ¹sandbox: sandbox é uma biblioteca que provê um ambiente especial durante as seguintes fases de compilação de um ebuild/pacote: src_unpack, src_compile, src_test e src_install. O sandbox encaixota este ebuild e previne que estes, acidentalmente, escrevam fora dos locais permitidos ou editem arquivos no momento da compilação. Dentro deste ambiente, todos os ebuilds, obrigatoriamente, devem ser construídos corretamente, não há espaço para truques aqui. Equivale ao fakeroot do Debian ou o InstallWatch das distros RPM.

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 I

Um olhar sobre o Portage Tools - Parte II

Leitura recomendada

Um tour pelos players de áudio para Linux

Mentis - Reprograme-se

Automatizando relatórios GLPI usando PHP e Shell Script

Criando máquinas virtuais e utilizando o VMWare-Player

Conheça a distribuição FAN Nagios

  
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
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts