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.
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.
Aqui está uma breve lista do que nós ganhamos trocando para ebuilds avulsas:
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.
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.
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:
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:
Listagem de código 3.1: Removendo KDE 3.4 do sistema |
# 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:
Listagem de código 3.2: Exemplo de uso das funções de kde-functions |
$ 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.