Como o Gentoo é um sistema todo compilado os usuários possuem um poder maior nas mãos sobre o que eles querem ou não habilitar em seu sistema. Logicamente isto exige um bom conhecimento por parte do usuário. Isto é muito útil e muito versátil para modificarmos nosso sistema. Grande parte desta flexibilidade é fornecida pelas chamadas USE flags.

As USE flags são funcionalidades que ativamos/desativamos globalmente ou em determinados pacotes para nosso sistema operar do modo que precisamos. Por exemplo, para um Desktop que será usado para jogos, é necessário setar algumas funcionalidades para que o software de emulação, ou o jogo em si, rode sem nenhum problema na nossa plataforma. Estas funcionalidades são implementadas através das USE flags. Neste cenário uma USE flag necessária seria a gecko, por exemplo, para que nosso emulador/jogo rode sob as características desta engine. Uma outra flag que poderíamos setar é a ncurses para jogos que utilizam tal biblioteca.

Mas estes são exemplos bem específicos. Geralmente é necessário setar estas flags se quisermos que nossos jogos tenham um bom rendimento. Mas e para softwares corriqueiros que vem, por padrão, inchados com tantas funcionalidades, muitas das quais nem sequer usaremos? Simples. Desabilitamos tais flags desnecessárias e compilamos o software com apenas o que precisamos e iremos utilizar. Logicamente que o usuário precisa saber o que ele quer ou não e que saiba quais flags são necessárias para o fim desejado. É por isto que digo e repito: a dificuldade do Gentoo não está em sua instalação, e sim em sua administração. Mas veremos que isto é um aprendizado muito interessante. O Gentoo possui centenas de USE flags, distribuídas entre duas categorias: flags globais e flags locais.

FLAGS GLOBAIS

São usadas por inúmeros pacotes e por nós mesmos, os usuários. Na verdade usamos e abusamos de tais flags. Podemos encontrar estas flags no arquivo: /usr/portage/profiles/use.desc. É com elas que trabalhamos diariamente habilitando ou desabilitando nos diversos softwares. Para que uma flag seja categorizada como global é preciso que satisfaça alguns critérios como:

• ser usada por, ao menos, 5 diferentes tipos de pacotes.
• possuir um propósito geral não específico.

Estes são pontos importantes pois se uma flag tem um comportamento substancialmente diferente entre dois pacotes, por exemplo, ela não deve ser uma flag global por conter tanta diversidade.

FLAGS LOCAIS

São mais restritas para que determinadas funcionalidades essenciais sejam habilitadas. Podemos encontrar a lista de flags locais no arquivo: /usr/portage/profiles/use.local.desc.

Para deixar mais claro como trabalhamos com as flags USE, vamos analisar o pacote app-admin/conky: Vamos olhar estas flags mais de perto.

Conky - local USE flags:

• apcupsd: habilita suporte ao daemon APC UPS, que pode ser usado como gerenciador de energia em um grande número de UPS (aqui no Brasil, NO-BREAK).
• audacious: habilita suporte ao audacious.
• cmus: cmus é um plugin de leitor de música escrito em ncurses, que roda diretamente do terminal. É bem interessante este programa.
• eve: flag que habilita algumas funcionalidades online para o conky
• ical: implementação básica dos protocolos do iCalendar
• iostats: habilita suporte de estatísticas de Input/Output por tarefa.
• irc: habilita suporte ao canal irc, através da biblioteca libircclient.
• lua-cairo: habilita suporte à LUA-CAIRO
• lua-imlib: habilita suporte à scripts LUA e à biblioteca de renderização de imagem: imlib.
• lua-rsvg: habilita suporte à scripts LUA e à biblioteca de renderização SVG.
• math: habilita suporte à biblioteca math de linguagem C do GNU.
• moc: outro player ncurses que roda diretamente do console.
• mpd: daemon de música (Music Player Daemon).
• nano-syntax: habilita sintaxe destacada do nano.
• nvidia: habilita suporte à leitura de sensores de temperatura através do pacote media-video/nvidia-settings.
• portmon: um daemon que monitora portas TCPIP(4).
• thinkpad: habilita suporte aos mousepads dos notebooks da IBM/Lenovo.
• weather-metar: ativa suporte à meteorologia.
• weather-xoap: ativa suporte à meteorologia através do serviço xoap.
• webserver: habilita suporte à biblioteca C libmicrohttpd, que roda serviços HTTPD como parte de outra aplicação.
• xmms2: nova geração do player XMMS.

Conky - global USE flags:

• X: adiciona suporte gráfico para o X.
• curl: adiciona suporte cliend-side para a biblioteca de transferência de URL.
• debug: habilita informações extras de debug.
• hddtemp: habilita suporte à leitura de temperatura do HD, através do pacote app-admin/hddtemp.
• iconv: habilita suporte à biblioteca de conversão de caracteres - libconv.
• imlib: adiciona suporte à biblioteca imlib, que carrega e renderiza imagens.
• ipv6: adiciona suporte à IPV6.
• mysql: adiciona suporte ao banco de dados mysql.
• ncurses: habilita suporte e uso da biblioteca ncurses.
• rss: habilita suporte à Feeds RSS.
• trutype: habilita suporte às fontes FreeType e FreeType2.
• vim-syntax: habilita suporte à sintaxe do vim.
• wifi: habilita funções do wireless.

Mas como estas flags se relacionam com o programa em si? Voltando aos artigos anteriores, expliquei brevemente sobre os ebuils, que nada mais são do que scripts shell que tem a função de preparar cada pacote para instalação no sistema. Estes são mantidos pelos desenvolvedores do Gentoo para manter a compatibilidade no sistema entre arquiteturas, demais programas, versões etc.

Falando especificamente das flags, cada ebuild possui uma instrução que indica quais flags estão habilitadas e quais não estão. Dependendo da flag, esta, por sua vez, pode puxar outras flags como dependência. A grosso modo há três variáveis que gerenciam dependências para os pacotes, incluindo as flags. Estas variáveis são a DEPEND, RDEPEND e PDEPEND. A variável DEPEND (build dependencies) especifica qualquer dependência que seja necessária para extrair, compilar, aplicar patches e instalar o pacote. E todos os pacotes possuem declarações implícitas sobre tempo de compilação e dependências sobre todo o sistema. Uma declaração básica desta variável pode ser o seguinte:


É possível declarar as versões das dependências:


Ou declarar as dependências dentro de um range:


Ou ainda por SLOTS:


Ou então para verificar se algumas das flags estão habilitadas ou desabilitadas:


A variável RDEPEND (runtime dependencies) especifica qualquer dependência que seja necessária em tempo de compilação. Isto inclui bibliotecas (linkadas dinamicamente) e quaisquer pacotes de dados e interpretadores (para linguagens interpretadas). Nos EAPI's anteriores ao 4, caso esta variável não estivesse definida, a ela seria atribuída, automaticamente, os valores da variável DEPEND. Porém o uso implícito era desaprovado. Com a chegada do EAPI4 isto foi abolido e a atribuição à variável DEPEND deve ser sempre feita de forma explícita. Portanto sempre encontraremos informações como estas nos ebuilds:


Ou apenas:


Entretanto há ebuilds que não especificam quaisquer dependências, pois não são necessárias. Neste caso também não será necessário declarar tais variáveis.

A variável PDEPEND especifica as dependências que devem ser instaladas após a instalação do pacote solicitado, mas esta dependência poderá ser instalada a qualquer momento. No geral o uso desta variável é evitada em favor da variável RDEPEND, exceto caso esta última cause dependências circulares¹.

Voltando às flags do conky, em seu ebuild tem declarado o seguinte:


Certo, todas as flags vistas no conky, estão ali, declaradas. Isto irá verificar se, por exemplo, o usuário habilitou a flag wifi. Caso positivo, haverá um trecho de código para esta situação. Não vou entrar nos detalhes dos ebuilds pois não é o caso no momento. Ficará para um futuro artigo.

Algumas flags podem vir ativadas por padrão por conta das flags que temos setadas no make.conf e/ou até mesmo pelo profile escolhido com o eselect. Entretanto, podemos escolher compilar sem as flags desejadas. Na próxima página veremos as formas para escolhermos as flags.

NOTA: [1] Dependência circular: dependência circular é quando um pacote A depende de um pacote B, que por sua vez depende do pacote A. Sendo assim ambos não podem ser instalados um antes do outro. A primeira vista parece um tanto quanto bizarro, mas é um problema relativamente fácil de resolver bastando desabilitar algumas ou apenas uma USE flag. O Portage informará o melhor caminho a tomar neste caso.