Um olhar sobre o Portage Tools - Parte II

Continuando com os arquivos do diretório /etc/portage/profiles, temos em seguida o arquivo packages.

packages: este arquivo prove a lista de pacotes que compõem os arquivos SET @system e @profile. Este é um arquivo de configuração como todos os outros.

• Comentários começam com (#).
• Deve ser informado apenas um ATOM como dependência (DEPEND) por linha.
• Pacotes que deverão ser adicionados ao @system, devem começar com *.
• Pacotes que deverão ser adicionados ao @profile, não necessitam de prefixo.

Por exemplo, se quisermos adicionar o pacote app-portage/eix/eix-0.30.4 ao @system, faremos desta forma:


packages.build: este arquivo é uma lista de pacotes (um por linha), que são utilizados para construir o tarball do stage1.

package.bashrc: contém lista de arquivos bashrc por pacote. Cada arquivo será processado antes de instalar (emergir) um pacote (atom).

package.provided: lista de pacotes que o Portage deve assumir que foi provisionado. Os pacotes aqui listados serão assumidos pelo Portage que não deverão ser instalados e nem atualizados, salvo se outro pacote explicitar que precisa de determinado (que estiver listado aqui) pacote atualizado.

package.use.force e package.use.stable.force: aqui forçamos determinados pacotes a serem instalados com determinadas USE flags habilitadas ou desabilitadas. Por ex.:


É importante notar que as flags devem ser separadas por um espaço após o pacote ser informado.

package.use.mask e package.use.stable.mask: neste arquivo especificamos determinados pacotes a serem mascarados com determinadas USE flags. O formato para inserir pacotes aqui, é o mesmo do arquivo anterior.

parent: este arquivo contém caminhos (paths), absolutos ou relativos, para os perfis.

profile.bashrc: caso necessário, este arquivo será usado para configurar ambientes especiais para os ebuilds de forma diferente da utilizada pelo ambiente root.

soname.provided: lista de bibliotecas compartilhadas (soname) que o Portage deverá assumir que já foi provisionado pelo usuário. Por ex.:


use.force e use.stable.force: força a instalação de pacotes com as USE flags listadas aqui.

use.mask e use.stable.mask: algumas USE flags que não fazem sentido serem habilitadas em determinadas arquiteturas, ou que ainda não foram exaustivamente testadas. Por exemplo: habilitar USE flags da arquitetura sparc em um x86.

virtuals: este arquivo controla preferências padronizadas que são definidas através da variável PROVIDE dos ebuilds, porém este tipo de arquivo não é mais suportado no Gentoo.

O fato acima se deve através de um projeto do Gentoo chamado de GLEP.

GLEP (Gentoo Linux Enhancement Proposal, ou, Proposta de Aprimoramento do Gentoo Linux) consiste em manter, solicitar e coletar propostas para melhorar o Gentoo. Qualquer usuário ou desenvolvedor pode enviar uma GLEP sugestionando possíveis melhorias para o sistema. Este é um dos caminhos que temos para interagir com os mantenedores do Gentoo.

Através da GLEP37 foi definido que o arquivo virtuals (e pacotes que entram nesta categoria) não seriam mais suportados pelo Gentoo. Segundo os autores desta GLEP - Thomas de Grenier de Latour, Ciaran McCreesh, Brian Harring and Stephen Bennett - este tipo de sistema é descentralizado e não há maneiras do Portage encontrar um pacote, de categoria virtual, específico. Assim o Portage precisaria verificar em todos os pacotes por esta categoria específica. Isto, claramente, provoca uma diminuição significativa de desempenho. Sendo assim, foi criada a GLEP37 que aboliu o sistema/pacotes virtuals.

Este projeto não é parte exclusiva do Portage, porém achei melhor explicar um pouquinho mais sobre o que envolve o Gentoo e suas ferramentas. Neste caso específico, esta GLEP está ligada diretamente ao Portage, sendo assim, creio que coube sua explicação.