O guia de ebuilds avulsas do KDE

1.  As ebuilds avulsas do KDE

O que elas são

Até janeiro de 2005, as únicas ebuilds de KDE no Portage eram 'monolíticas'. Isto é dizer, eram só 15 ebuilds, e cada uma instalava muitas aplicações que, de fato, não dependiam uma da outra. Isto era claramente uma situação sub-otimizada, e não muito do estilo do Gentoo, mas foi tolerada por muito tempo.

As novas ebuilds 'avulsas' consertaram a situação oferecendo ebuilds separadas para todas aplicações do KDE. Isto nos deu um novo total de cerca de 230 novas ebuilds na categoria kde-base.

Nós ainda providenciamos ebuilds monolíticas para o KDE 3.4 e elas são limpamente inter-operáveis com as avulsas. Todavia, as ebuilds avulsas são o novo padrão, e não haverá ebuilds monolíticas para o KDE 4.0.

Finalmente, deve ser mencionado que há ebuilds avulsas para Koffice também. Elas fornecem kword, kugar, etc... como pacotes separados.

Como instalar as ebuilds avulsas

O último pré-lançamento do KDE 3.4.0, na época desta escrita, é 3.4.0_beta1. Ebuilds mascaradas avulsas (e monolíticas) estão presentes no Portage. O último lançamento do KDE, na época desta escrita, é 3.4.1, recentemente marcado como estável. Tanto ebuilds avulsas como monolíticas estão disponíveis no Portage.

• Para fazer emerge de um pacote particular, como kmail, simplesmente faça emerge kmail.
• Para fazer emerge do ambiente básico de KDE permitindo que você faça log-in em uma sessão de KDE minimalística, faça emerge kdebase-startkde.
• Finalmente, para o equivalente exato de um dos pacotes monolíticos - por exemplo, para ter todas aplicações inclusas no kdebase usando ebuilds avulsas - você pode fazer emerge kdebase-meta (ou kdepim-meta, etc.) Para obter todas ebuilds avulsas do KDE, faça emerge kde-meta.

Como atualizar de ebuilds monolíticas para avulsas

Se você tem o KDE 3.3.x instalado, você pode simplesmente rodar emerge kde-meta para instalar as ebuilds avulsas de 3.4.x sem perturbar sua instalação existente.

Se você tiver ebuilds monolíticas de KDE 3.4.x instaladas, você precisa desinstalá-las antes de instalar as ebuilds avulsas. No entanto, este processo pode ser feito para cada ebuild monolítica. Você não precisa desinstalar o KDE inteiro de uma vez.

Se você estiver em dúvida, lembre-se que há dependências de bloqueio entre cada ebuild monolítica e ebuilds avulsas derivadas delas. O Portage não irá permitir que um estado ilegal seja criado, portanto qualquer instalação ou desinstalação que ele permitir não terá problemas.

Vantagens das ebuilds avulsas

Aqui está uma breve lista do que nós ganhamos trocando para ebuilds avulsas:

• A maior parte dos pacotes de KDE não muda nada entre pequenos lançamentos do KDE. Por exemplo, a atualização do 3.3.1 para o 3.3.2 mudou menos que 100 pacotes de 320. Pacotes avulsos permitem que nós criemos ebuilds só para os pacotes que realmente mudaram, salvando (neste exemplo) mais de dois terços de tempo de compilação em uma atualização.
• Patches normalmente afetam um pacotes específico. Com ebuilds avulsas, eles podem ser testados, aprovados e contribuídos mais rapidamente, e os desenvolvedores tem menos a fazer; e, como acima, o usuário irá gastar menos tempo atualizando. Isto é especificamente importante para atualizações de segurança.
• Usuários de outros desktops e WMs diferentes podem fazer emerge de poucas aplicações de KDE de que gostam sem a (grande) carga do resto de, digamos, kdebase ou kdepim.
• Usuários podem ajustar cuidadosamente que pacotes têm instalados. Razões para querer isto incluem:
  • Você se importa com tempo de compilação. emerge kdebase kdepim kdenetwork leva muito tempo quando só o que você precisa é o konqueror, kmail e kopete. Aliás, tempo de processador é dinheiro... em algum lugar.
  • Você se importa com uso de disco. Cada pacote não usado significa muitos megabytes bloqueando os poros entre os setores de seu disco. Um disco com mais espaço livre respira livremente; é um disco rápido e feliz.
  • Você se importa com a segurança do sistema. Todo software instalado é uma fonte potencial de vulnerabilidades, e não há desculpa para software não-usado ficar por aí.
  • Você adere fielmente ao Modo do Gentoo, e não pode tolerar que pacotes sejam colocamos juntamente e forçados ao usuário. (Nós também não.)
• Finalmente, as ebuilds avulsas também permitem maior flexibilidade na hora da compilação com as variáveis de USE.

Inter-operabilidade de ebuilds avulsas e monolíticas

Ebuilds avulsas e monolíticas podem ser misturadas livremente. A única restrição é que uma ebuild monolítica não pode ser instalada junto com uma ebuild avulsa que deriva dela. Existem dependências de bloqueio nas ebuilds que garantem isso, então você pode fazer qualquer coisa que o emerge permitir.

Ordinariamente, no entanto, não há motivo para usar uma configuração mista. Na verdade, fora casos especiais como máquinas que compilam muito lentamente (mips), você deve usar ebuilds avulsas para todas suas necessidades.

As ebuilds avulsas também são as ebuilds padrão. Isto significa que quando alguma outra ebuild depender de uma aplicação de KDE, ela irá instalar a ebuild avulsa. Todavia, a ebuild monolítica correspondente também irá satisfazer a dependência, então você pode fazer emerge da ebuild monolítica manualmente e então fazer emerge da ebuild que dependia dela.

2.  Problemas de performance

Por que ebuilds avulsas são lentas

Já foi dito antes que ebuilds avulsas iriam levar muito mais tempo para fazer emerge que as monolíticas, devido à carga de desempacotar e rodar configure para cada pacote. Um emerge kde-meta pode levar de 20-30% a mais de tempo que um emerge kde clássico, algo inaceitável em uma compilação já muito longa.

Adicionalmente, atualmente as ebuilds avulsas sempre rodam make -f admin/Makefile.cvs (isto significa rodar autoconf, automake, etc. e vários scripts relacionados especificamente ao kde). Isto adiciona uma lentidão de aproximadamente a mesma ordem que rodar configure.

Em face disto, a análise parece ser desoladora. No entanto, vários fatores que cobrem esta lentidão serão detalhados nas seção a seguir.

Vale reiterar aqui que com as ebuilds avulsas o tempo de compilação de uma atualização do KDE pode ser cortado pela metade - e em alguns casos por um fator de dez ou mais - ao só atualizar os pacotes que realmente mudaram. O benefício de uma atualização simples de uma atualização normalmente cobre a carga adicional tomada durante a instalação original.

Finalmente, instalar tudo do KDE faz sentido se você quiser explorar todos pacotes disponíveis ou estiver configurando um ambiente multi-usuário; porém, a maior parte das pessoas usa só algumas das mais de 300 aplicações de KDE disponíveis. Qualquer pessoa que se importa com tempo de compilação, como proprietários de máquinas antigas, podem ganhar mais tempo ao instalar pacotes seletivamente que perdem pela carga adicional incorrida.

Como as ebuilds avulsas serão agilizadas

A melhoria mais óbvia seria distribuir tarballs separadas para as ebuilds avulsas, ao invés de desempacotar pedaços das tarballs monolíticas (kdebase etc...) distribuídas pelos desenvolvedores. Isto eliminaria dois dos três fatores de carga que tornam as ebuilds avulsas lentas: extração repetitiva das grandes tarballs e regeração de makefile (a fase make -f admin/Makefile.cvs mencionada acima).

Isto nos deixa com o problema de rodar o configure repetidamente. A solução adequada para isto é o confcache: um cache de configure compartilhado entre as vezes que o emerge é rodado. Uma implementação já existe no ramo de desenvolvimento do portage (a ferramenta, não a árvore de pacotes); um lançamento estável com confcache é esperado dentro de meio ano.

Outros fatores que superam a lentidão das ebuilds avulsas

A seção anterior listou métodos de melhorar a performance das ebuilds avulsas especificamente. A seguir nós iremos mencionar brevemente algumas melhorias futuras que são igualmente aplicáveis a ebuilds monolíticas. Tais melhorias ajudam a tornam ebuilds avulsas 'rápidas o suficiente', a parte de comparações com soluções de menos funções como as ebuilds monolíticas.

• KDE 4.0 deve ser capaz de usar unsermake ao invés de automake, que melhora o tempo de compilação em alguns cenários; nossas ebuilds de KDE 3.4 podem acabar usando unsermake também.
• As ebuilds avulsas suportam a opção de USE kdexdeltas, que permite baixar diffs binários entre as tarballs de lançamento para economizar uso de banda.
• Todas outras ferramentas envolvidas na construção também geralmente ficam mais rápidas com o tempo, ou ativam melhorias na compilação relacionada ao KDE. As novas funções visibility=hidden (GCC 3.4) e cabeçalhos pré-compilados (GCC 4.0) são dois exemplos recentes. Eles não são resultados da troca para ebuilds separadas; só significam que podemos fazer compilações mais intensas nos processadores agora.

3.  Perguntas freqüentemente feitas das ebuilds avulsas

Nós já não podemos fazer isto com DO_NOT_COMPILE?

DO_NOT_COMPILE é uma variável de ambiente interna ao sistema de construção do KDE. Ela permite desativar subdiretórios seletivamente durante a compilação. Algumas pessoas usavam-na para compilar subconjuntos de ebuilds monolíticas do KDE. Por exemplo, rodar DO_NOT_COMPILE=konqueror emerge kdebase iria instalar um kdebase sem a aplicação konqueror.

No entanto, DO_NOT_COMPILE nunca teve a intenção de interferir com a operação das construções automáticas de um gerenciador de pacotes. Não funciona, pode quebrar seu sistema, e nunca foi suportado. Nós pedimos a todos que não usem DO_NOT_COMPILE.

Aqui está uma lista parcial de problemas com DO_NOT_COMPILE:

• Quebra o rastreamento de dependências do portage. O portage não sabe sobre o DO_NOT_COMPILE, e acha que um pacote monolítico inteiro foi instalado e pode satisfazer as dependências de outros pacotes. Isto pode fazer com que outros pacotes não instalem ou rodem.
• Força o usuário a conhecer os nomes e significados de todos subdiretórios diferentes existentes dos módulos do KDE. Muitos poucos usuários sabem, a menos que sejam desenvolvedores do KDE, então não podem usar DO_NOT_COMPILE adequadamente.
• Subdiretórios de módulos do KDE podem ter interdependências entre si, precisar de uma ordem de construção particular, precisar que outro diretório esteja presente mesmo se não for instalado, e assim em diante. Nós trabalhamos muito nas ebuilds avulsas para que funcionem bem neste aspecto. DO_NOT_COMPILE não é uma ferramenta fina o suficiente para obter os mesmos resultados, mesmo que o usuário tenha conhecimento suficiente. A única coisa que você pode fazer com ela é desativar a compilação de algumas aplicações. É praticamente impossível usá-la para instalar apenas algumas aplicações seletas de módulos como kdebase ou kdepim.
• Se eu instalei o kmail ontem e quero adicionar o korn hoje, usando DO_NOT_COMPILE, significa recompilar o kmail também. Isto quer dizer que DO_NOT_COMPILE é sempre mais lento que ebuilds avulsas.
• DO_NOT_COMPILE não pode ser usado para fazer pacotes pré-compilados (como o GRP) contendo aplicações de KDE individuais.

Você não está colocando uma grande carga nos mantenedores do KDE do Gentoo?

Surpreendentemente, esta questão é muito comum. Fico feliz que os usuários tem tanta consideração de nós mantenedores. Deixe-me tomar esta oportunidade para garantir que nós estamos tomando as ebuilds avulsas por conta própria; que acreditamos que poderemos continuar mantendo-as bem; e que não há chance de convencer-nos do contrário :-)

Para ser completo, devo mencionar que mantenedores de outras arquiteturas reclamaram sobre a carga de trabalho de testar e marcar tantas ebuilds separadas. Estamos tentando resolver o problema é um grande motivo pelo qual ebuilds monolíticas ainda estão disponíveis para o KDE 3.4.

Você irá remover as ebuilds de estilo antigo (monolíticas)?

Temos a intenção de fazer um dia. No entanto, haverá tanto ebuilds monolíticas como avulsas para todos lançamentos do KDE 3.4.

Se você preferir ebuilds monolíticas a avulsas, por favor conte-nos seus motivos.

Existem muitas ebuilds! Como irei encontrar a que preciso?

Bem, primeiro de tudo, se você sabe que o pacote que você está procurando veio com o kdebase, você ainda poder fazer emerge kdebase-meta, com resultados muito parecidos a fazer um emerge do kdebase monolítico. Então as coisas não ficaram na verdade piores por causa das ebuilds avulsas.

Claro, todas formas normais de localizar um pacote aplicam-se. Como você encontraria sua ebuild se fosse uma aplicação de Gnome? No mínimo, você tem que saber o nome da aplicação que está procurando.

A situação pode, talvez, ser melhorada introduzindo algumas mais ebuilds -meta. Elas são meramente listas de dependências, então não custam nada para nós. Isto ainda não foi decidido. Também, seria bom ter conjuntos de funcionalidade do Portage antes de fazermos isto extensivamente.

Como posso desinstalar um KDE antigo?

Suponha que saia o KDE 4.0 e você quer desinstalar todas ebuilds avulsas para KDE 3.4. Já que pertencem a slots separados, o emerge não fará isto para você, então outro método é necessário.

Uma solução adequada para este problema precisa de modificações no portage. Uma solução é descrita na GLEP 21. Até implementada, no entanto, precisamos usar scripts como o abaixo.

Felizmente, todas ebuilds de KDE pertencem ao diretório kde-base (e todas ebuilds na categoria kde-base vem do kde.org). Então o seguinte código funciona:

# for x in `ls /usr/portage/kde-base`; do
> if [ "$x" != "CVS" ]; then
> echo -n "=kde-base/$x-3.4* "
> fi
> done |xargs emerge -Cp

O código acima parece meio um hack, mas no final das contas não é um porque tudo que realmente precisamos é uma lista de ebuilds do kde-base. Isto é uma tarefa muito simples e sempre haverá formas fáceis de consegui-la.

Como posso listar/desinstalar todas ebuilds avulsas derivadas de um dado pacote?

O objetivo aqui é listar todas ebuilds avulsas do kde derivadas de, digamos, a ebuild monolítica kdebase. Novamente, a implementação adequada (como GLEP 21) tornaria isto trivial. Hoje, no entanto, você deve envolver-se com os detalhes d a implementação de eclasses do KDE até um certo grau. Então, se você usar qualquer um dos seugintes métodos em um script que não é de uso privado, por favor conte-nos sobre ele.

kde-functions.eclass define funções chamadas get-parent-package() e get-child-packages() que fazem a tradução para você. Estas duas funções são o jeito correto de conseguir esta tarefa de uma ebuild ou script de bash externo. Aqui está um exemplo:

$ function die() { echo $@; } # chamada para relatar erros
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # não funciona, você deve especificar nome inteiro
Package konqueror not found in KDE_DERIVATION_MAP, please report bug # erro impresso
$ get-parent-package kde-base/konqueror # nome de pacote inteiro
kde-base/kdebase # resultado impresso
$ get-child-packages kde-base/kdebase
 # (longa lista de pacotes impressa aqui)

Se seu script não for em bash, você pode fazer grep kde-functions.eclass para extrair a definição (multi-linhas) da variável KDE_DERIVATION_MAP, que as funções mencionadas usam. A variável contém uma lista de palavras separadas por espaços brancos, e cada duas palavras consecutivas mapeiam um pacote pai a uma ebuild avulsa filha.

O conteúdo deste documento está licenciado pela licença Creative Commons - Attribution / Share Alike.