De todas as features prometidas para o Fedora 11 a que mais aguardo é o “Presto“1. Apesar do nome meio bobnho a adição do presto como um padrão no Fedora vai beneficiar a todos os usuários com as
maravilhas do Delta RPM — Enfim, vou poder parar de babar em cima do openSuse, que já trazia o recurso há algum tempo.
O Delta RPM foi uma grande sacada dos engenheiros da Novell, eles pensaram: “Ei! Por que baixar o RPM inteiro toda vez que acontece um update? E se fosse possível baixar só a parte que teve update e juntá-la com o software a ser atualizado?”. Pois funcionou. Um Delta RPM pode gerar economias de mais de 90% em downloads (minha conexão de 300 Kb agradece).
Os usuários do Fedora, na verdade, já podem testar o Delta RPM há algum tempo (desde o Fedora 7 se não me engano), mas essa feature sempre ficou meio “de lado”, como um tipo de recurso à moda “amanhã eu testo”.
A desvantagem de usar Delta RPM agora é que a produção em massa de pacotes ainda não começou e quase tudo estava limitado aos esforços de Jonathan Dieter que mantinha os repositórios de Deltas. Isso significa que os updates em Delta podem demorar um pouco, mas sempre chegam.
Com aproximadamente 200 usuários usando o Presto atualmente os resultados não poderiam ser mais positivos. Usei durante mais de um ano (meio preocupado, devo confessar), mas tudo correu sem problemas.
Com a chegada do Presto, um desafio de infraestrutura começou no Projeto Fedora: fazer com que cada RPM tenha sua contraparte Delta da forma mais elegante possível. Para entender melhor, saiba que o Projeto Fedora usa dois sistemas para gerar seus pacotes e organizar tudo: Koji é o responsável pela construção de pacotes em todas as arquiteturas e Bodhi, que é o responsável por testar cada pacote e dar-lhes destino para os repositórios certos. Na fase atual, a equipe de infra está hackeando o Bodhi para que ele gere os deltas e estão lidando com problemas do tipo “Onde guardar os deltas?” ou “Como gerar os deltas? Na hora exata em que o RPM é feito ou fazer tudo de uma vez só depois?”. Além disso surgiu um problema de lógica. Vamos pensar o seguinte:
- Saiu o software chamado generic-0.1;
- Com o passar do tempo ele sofre três atualizações: generic-0.2, generic-0.3 e generic-0.4
- Você, caro leitor, que é um cara antenado a gosta sempre de estar “na crista da onda”, vai ter seu software sempre atualizado, portanto, estará usando o generic-0.4
- Manoel, que não gosta de atualizar ou que não atualiza frequentemente ainda está no generic-0.2, mas decidiu atualizar agora, direto do 0.2 pro 0.4.
Quantos Delta RPMs são precisos gerar para garantir que seja possível atualizar de todas as versões para uma mais atual (não necessariamente A mais atual) sem excluir ninguém?
Entenda-se nessa questão o seguinte: é preciso garantir que existam Delta RPMs para todas as possibilidades de atualização, logo, existe necessidade de garantir que seja possível atualizar de generic-0.1 para generic-0.2, de generic-0.1 para generic-0.3, de generic-0.1 para generic-0.4, de generic-0.2 para generic-0.3, de generic-0.2 para generic-0.4 e de generic-0.3 para generic-0.4 (sem excluir nenhuma possibilidade).
Se achou tudo isso muito complicado, basta dizer que para cada versão de um software, se ele tiver n versões será preciso gerar [pmath size=10](n^2-n)/2[/pmath] Delta RPMs. Ou seja: se o Firefox tiver 5 versões nos repositórios vamos precisar de[pmath size=10](5^2 — 5)/2 = 10[/pmath] Delta RPMs para ele.
A chance de tudo estar pronto para o Fedora 11 é grande (95% até o momento) e eu estou na torcida, acompanhando cada passo como se fosse o novo capítulo daquela novela mexicana favorita. =) Me deem um desconto, conexão de 300 Kb…
Quer testar o Delta RPM no seu fedora?
Instale o plug-in:
# yum install yum-presto
Habilite o repositório de Delta RPMs:
No Fedora 10 edite o arquivo /etc/yum.repos.d/fedora-updates.repo. Comente o mirrorlist antigo e adicione este novo:
mirrorlist=http://presto-mirrors.anmar.eu.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
No Fedora 9 edite o arquivo /etc/yum.repos.d/fedora-updates-newkey.repo. Comente o mirrorlist antigo e adicione este novo:
mirrorlist=http://presto-mirrors.anmar.eu.org/mirrorlist?repo=updates-released-f$releasever.newkey&arch=$basearch
———————————-
- http://fedoraproject.org/wiki/Releases/FeaturePresto ↩

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
{ 1 trackback }
{ 8 comments… read them below or add one }
Eu acho que a solução para o Manoel seria o yum baixar automaticamente os deltas 0.3 e 0.4 e aplicá-las na ordem.
Realmente é fascinante… Estou atualizando meu Fedora agora e assim que finalizar irei configurar meu Delta RPM.
Eu ja tinha ouvido falar, mas nunca parei para configurar, achei que ainda era muito instável e minha maquina de teste está com problemas. sendo assim não queria fazer testes em meu note de trabalho, mas irei testar nele mesmo.
Obrigado
Muito interessante a notícia. Em ultima ratio, o delta rpm é a singularização do conteúdo dos rpms, não? Pacotes de conteúdo único.
Não ficou claro no seu exemplo a frase: “Apenas no nosso exemplo, 9 deltas seriam necessários”, ainda mais quando estamos tendo em mente apenas 4 versões do mesmo pacote.
Para mim, sempre achei que os arquivos .conf deveriam ser guardados em pacotes isolados. Esses arquivos nunca ou quase nunca mudam. Nem duvidaria que um generic-0.2, generic-0.3, generic-0.4, generic-1.1 e generic-1.2, tivessem exatamente o mesmo /etc/generic.conf.
Salve, Mitulino.
O delta rpm contém, na verdade, um “diff” entre o pacote antigo e o pacote novo. Quando instalado, o Delta se “aplica” ao software existente. Um Delta RPM é, simplificando muito, um tipo de patch.
Adicionei alguma matemática para maior entendimento. Espero que me perdoem…
Cara###!!! Eu te disse que era assim que o Foresight atualizava seus pacotes e você falava “Mas aí tem que recompilar! Mas aí tem que blá-blá-blá!” Eu vou te bater! auhauhaua
Hahaha Eu nem lembrava disso. =P
Putz, mas se é dessa maneira, crescendo com n^2, eu acho que dará um trabalho danado! Mesmo sendo uma boa coisa para pessoas com conexão lenta — embora isso não resolva o problema de pessoas com conexão discada e julgo que deveria ter algo também no Fedora —, isso vale mesmo a pena dessa maneira, quer dizer, o quão viável é isso?
Se deu certo antes, pode ser que dê agora..