Monthly Archive for janeiro, 2009

A pala­vra RPM é um acrô­nimo recur­sivo que sig­ni­fica RPM Package Mana­ger. De modo resu­mido ele é o equi­va­lente aos paco­tes .deb ou, se pre­fe­rir, aos arqui­vos .exe do Win­dows, já que serve para ins­ta­lar, desins­ta­lar e atu­a­li­zar arqui­vos e/ou softwa­res no sis­tema operacional.

Se você não gosta de his­tó­ria, pode pular a seção seguinte e ir direto para “Como funciona?”.

Um pouco de história

No iní­cio da década de 90 já era evi­dente a neces­si­dade de criar um “geren­ci­a­mento de paco­tes” que fosse fun­ci­o­nal e sim­ples de usar. Até então, o método mais comum de ins­ta­la­ção de softwa­res era a tra­di­ci­o­nal com­pi­la­ção e ins­ta­la­ção direta pelo código fonte. Esse método, no entanto, era uma clara des­van­ta­gem por­que excluía os usuá­rios menos téc­ni­cos e fazia com que o sis­tema ope­ra­ci­o­nal tivesse quase ou nenhum con­trole sobre os softwa­res que eram ins­ta­la­dos. Era comum que um soft­ware não pudesse mais ser desins­ta­lado ou que, para garan­tir a desins­ta­la­ção, o código fonte tivesse que ser man­tido no sis­tema. Foi por isso que a Red Hat ini­ciou as pes­qui­sas em busca de um método de geren­ci­a­mento de paco­tes que fosse efe­tivo e simples.

RPP

Foi o nome do geren­ci­a­dor de paco­tes usado pelos pri­mei­ros Red Hats. O RPP foi a “musa ins­pi­ra­dora” para mui­tas das habi­li­da­des que o RPM de hoje em dia aca­bou her­dando. Ele tinha uma uti­li­za­ção sim­ples, bas­tando uma linha de comando para ins­ta­lar um pacote; per­mi­tia a exe­cu­ção de scripts de pré e pós instalação/desinstalação; era capaz de fazer uma veri­fi­ca­ção dos paco­tes para des­co­brir se alguma alte­ra­ção nos arqui­vos tinha sido feita e sal­vava as infor­ma­ções do pacote (como des­cri­ção, ver­são, nome e lis­tas de paco­tes) em um banco de dados. Aca­bou não vin­gando por­que, embora fosse rela­ti­va­mente efi­ci­ente, não con­se­guia tra­ba­lhar com o código fonte ori­gi­nal dos softwa­res que ins­ta­lava. Isso que­ria dizer que cada empa­co­ta­dor pre­ci­sava hac­kear o soft­ware antes de empacotá-lo para que ele fun­ci­o­nasse bem com o RPP. Além disso, o RPP era inca­paz de tra­ba­lhar com arqui­te­tu­ras dife­ren­tes da x86… Embora tenha sido o geren­ci­a­dor de paco­tes RPP o grande dife­ren­cial da Red Hat no iní­cio da empresa, logo ficou claro que a limi­ta­ção de não poder tra­ba­lhar com outras arqui­te­tu­ras viria a se tor­nar um pro­blema e por esse motivo, as pes­qui­sas por um geren­ci­a­mento melhor de paco­tes continuou.

PMS (Pac­kage Mana­ge­ment System)

O PMS não foi desen­vol­vido pela Red Hat. Ao con­trá­rio, era desen­vol­vido por um grupo de desen­vol­ve­do­res che­fi­a­dos por Rik Faith que cri­a­ram a dis­tri­bui­ção cha­mada Bogus Linux . Os paco­tes PMS não eram muito bons por­que usa­vam um banco de dados pobre­mente dse­nhado e facil­mente cor­rup­tí­vel, tam­bém esta­vam limi­ta­dos a ape­nas uma arqui­te­tura mas intro­du­zi­ram o con­ceito de tra­ba­lhar dire­ta­mente com o código fonte do “ups­tream” (i.e. dos desen­vol­ve­do­res ori­gi­nais). Qual­quer mudança neces­sá­ria para que o soft­ware fun­ci­o­nasse era apli­cada por sim­ples patches.

PM

Pouco depois, Rik Faith e Doug Hoff­man , já con­tra­ta­dos pela Red Hat, con­ti­nu­a­ram tra­ba­lhando num geren­ci­a­dor de paco­tes e desen­vol­ve­ram o PM, que jun­tava todas as van­ta­gens do RPP e do PMS. Infe­liz­mente, her­dou tam­bém as fra­que­zas dos dois geren­ci­a­do­res de paco­tes e pos­suía um banco de dados muito cor­rup­tí­vel, além de, claro, con­ti­nuar sendo com­pa­tí­vel com somente um tipo de arquitetura.

RPM 1 (Finalmente)

Espelhando-se nas duas bem suce­di­das ten­ta­ti­vas de cri­a­ção de geren­ci­a­mento (RPP e PMS), Marc Ewing e Erik Troan come­ça­ram a tra­ba­lhar em um ter­ceiro geren­ci­a­dor de paco­tes que se cha­ma­ria RPM (Red Hat PackageManager).

Ape­sar de ins­pi­rado pelo RPP, PMS e PM, o RPM iria focar em resol­ver todos os pro­ble­mas que esses geren­ci­a­do­res antes não tinham con­se­guido resol­ver. A lin­gua­gem de pro­gra­ma­ção esco­lhida foi o Perl, por ser fácil e rápido de programar.

Ape­sar do RPM 1 ter sido, rela­ti­va­mente, um êxito, apre­sen­tava diver­sos problemas:

• Era muito mais lento do que se tivesse sido escrito em C;
• O banco de dados era extre­ma­mente frá­gil e que­bra­diço, corrompendo-se à toa;
• Não era pos­sí­vel exe­cu­tar o geren­ci­a­dor por um dis­quete, já que o fato de ser escrito em perl con­su­mi­ria um espaço extra;
• Embora fun­ci­o­nasse em outras arqui­te­tu­ras, o fun­ci­o­na­mento ocor­ria com problemas
• O geren­ci­a­dor de paco­tes não era “expan­sí­vel’. O que sig­ni­fi­cava que qual­quer mudança maior no código faria com que os paco­tes ante­ri­o­res se tor­nas­sem incom­pa­tí­veis com as ver­sões futuras.

RPM 2

Marc e Eric rees­cre­ve­ram o RPM total­mente, usando dessa vez a lin­gua­gem C. Essa deci­são aumen­tou em muito a velo­ci­dade de exe­cu­ção do geren­ci­a­dor de paco­tes. Adi­ci­o­nal­mente, o banco de dados foi rede­se­nhado e per­mi­tia que as con­sul­tas fos­sem exe­cu­ta­das em 1/10 do tempo que antes era tomado pelo RPM 1. Atu­al­mente, o RPM está na ver­são 4.4.2.3.

Como fun­ci­ona?

Um RPM é, na ver­dade, um meta pacote. Para faci­li­tar o enten­di­mento, pense nele como um pacote com diver­sos rótu­los cola­dos nele e que cada um des­ses rótu­los con­tém um tipo de infor­ma­ção que é “inte­res­sante” que seu sis­tema saiba. O soft­ware que você deseja ins­ta­lar está lá, com­pac­tado por um pro­cesso antigo e efi­ci­ente cha­mado cpio.

O que vem no RPM está “pré-compilado”. Isso quer dizer que o soft­ware foi pre­pa­rado em outra máquina, o resul­tado da com­pi­la­ção foi empa­co­tado e tudo que você faz é ins­ta­lar o soft­ware pronto para usar.

A ana­to­mia de um pacote RPM é a seguinte:

1. O iní­cio do pacote RPM é a “guia” que ensina ao sis­tema ope­ra­ci­o­nal que se trata de um pacote RPM. Nessa seção exis­tem cabe­ça­lhos lidos pelo sis­tema que são impor­tan­tes para o manu­seio do pacote. Aqui cabe uma boa ana­lo­gia com o GRUB.
2. Esta seção arma­zena assi­na­tu­ras que garan­tem a auten­ti­ci­dade dos paco­tes. É pos­sí­vel, por exem­plo que um dis­tri­bui­dor assine seus RPMs com sua pró­pria marca, que é iden­ti­fi­cada pelo sis­tema. Isso reforça a segu­rança e per­mite a um usuá­rio ins­ta­lar (ou não) somente softwa­res dis­po­ni­bi­li­za­dos por dis­tri­bui­do­res cuja assi­na­tura seja con­fiá­vel (como Fedora, Red Hat, Man­driva, Opensuse…).
3. Na ter­ceira seção per­ma­ne­cem as infor­ma­ções como nome do soft­ware, ver­são, rele­ase, des­cri­ção, lista de arqui­vos, depen­dên­cias… Essas entra­das são arma­ze­na­das no banco de dados do RPM.
4. A quarta (e maior) seção con­tém, final­mente, os arqui­vos com­pac­ta­dos. Na figura ela é repre­sen­tada por .tar.gz mas isso é mera­mente ilus­tra­tivo. Na ver­dade, o método de com­pres­são é o cpio. Cada pacote RPM tem uma limi­ta­ção de tama­nho: 2 GB para sis­te­mas 32 bits e 4 GB para sis­te­mas 64 bits.

Agora que você já entende como é um pacote RPM, está pronto para des­co­brir o que ele faz. Não vou entrar aqui em deta­lhes de como criar um pacote, isso foge ao escopo do nosso artigo, no entanto, de qual­quer forma, antes de botar a mão na massa para fazer um RPM é sem­pre bom enten­der como ele funciona.

Quando você ins­tala um soft­ware qual­quer com o ./configure, make e make install, ele veri­fica se seu sis­tema está ok para rodá-lo, busca as pas­tas cor­re­tas, gera os links, ins­tala as pági­nas de manual e exe­cuta quais­quer outras ope­ra­ções neces­sá­rias. Num pacote RPM ocorre exa­ta­mente o mesmo, mas o soft­ware é enga­nado e acaba se ins­ta­lando numa árvore de dire­tó­rios falsa cha­mada “fake root”. A árvore falsa é exa­ta­mente igual á árvore do seu sis­tema ope­ra­ci­o­nal, mas é “vazia”, sem nenhum outro soft­ware; tudo que existe nessa árvore falsa é o soft­ware que foi “enga­nado” e se ins­ta­lou na árvore de dire­tó­rios falsa. Depois disso, o soft­ware que monta os RPMs (cha­mado RPM­Build) pega essa árvore falsa e a com­pacta den­tro do pacote.

Durante a ins­ta­la­ção do soft­ware que, agora, está den­tro do RPM o soft­ware é des­com­pac­tado e “colado” em cima da árvore de dire­tó­rios de verdade.

Como a árvore falsa e a árvore ver­da­deira são exa­ta­mente iguais, o resul­tado disso é que o RPM acres­centa o novo soft­ware com seus arqui­vos, links e docu­men­ta­ções à árvore exis­tente, algo muito pare­cido com um “copiar e colar” em larga escala.

Tudo que você ins­ta­lou via RPM fica regis­trado num banco de dados SQLite que fica loca­li­zado em /var/lib/rpm (mas não tente abrir esse banco de dados dire­ta­mente, geral­mente o resul­tado é amargo). Se seu RPM foi bem feito ele con­tém uma lista de todo e qual­quer arquivo que foi copi­ado para o seu HD. Cabe ao pro­gra­ma­dor do pacote (empa­co­ta­dor) dizer ao RPM o que ele está jogando no disco, caso con­trá­rio, um RPM mal feito, ao ser desins­ta­lado, pode dei­xar lixo inú­til para trás.

Um pacote RPM é, afi­nal, algo muito simples.