Como um pacote RPM chega no YUM?

Desde que inven­ta­ram os geren­ci­a­do­res de paco­tes e apli­ca­ti­vos como YUM e apt-get, ins­ta­lar softwa­res no Linux ficou até mais sim­ples do que ins­ta­lar um soft­ware no Win­dows, basta uma linha de comando tão sim­ples quanto “yum ins­tall pacote” e a mágica acontece.

Como pri­meiro post desse ano, esco­lhi mos­trar como são os bas­ti­do­res de envio de paco­tes para o YUM, ou seja: como um soft­ware chega da fonte ori­gi­nal até o seu Fedora.

A pri­meira coisa a fazer é escla­re­cer que o Pro­jeto Fedora tem deze­nas de empa­co­ta­do­res e que esses empa­co­ta­do­res fazem parte de um grupo cha­mado “pac­ka­gers”, que tem per­mis­sões espe­ci­ais de acesso. Cada empa­co­ta­dor é res­pon­sá­vel por gerar o RPM para um ou mais softwa­res que ele “adota”; ou seja: o empa­co­ta­dor encon­tra um soft­ware inte­res­sante em qual­quer lugar (Sour­ce­forge, Laun­ch­pad etc) e decide criar um RPM ofi­cial para o Fedora.

A sub­mis­são de um pacote é bas­tante rigo­rosa e pode levar meses para que um pacote seja apro­vado. É pre­ciso seguir à risca toda a meto­do­lo­gia de empa­co­ta­mento e que o soft­ware a ser empa­co­tado seja con­si­de­rado “livre” o bas­tante para entrar no Fedora (diver­sos revi­so­res ava­liam o RPM, ana­li­sando o código e a licença). Os deta­lhes desse pro­cesso são irre­le­van­tes para este artigo; o que nos inte­ressa aqui é que, para enviar o pacote aos repo­si­tó­rios, é pre­ciso ser um empacotador.

Diver­sas fer­ra­men­tas foram pre­pa­ra­das de modo a faci­li­tar a vida de quem empa­cota para o Pro­jeto Fedora e basta executar

para ins­ta­lar uma cole­ção de scripts e fer­ra­men­tas essen­ci­ais para a cri­a­ção de RPMs e para o envio dos paco­tes pron­tos para os ser­vi­do­res do Pro­jeto (com­pi­la­do­res, cvs, rpmbuild…).

Após ins­ta­lar o “fedora-packager”, é pre­ciso executar

na pasta home do usuá­rio. Este comando pre­para o ambi­ente de desen­vol­vi­mento, ajus­tando as macros para o rpm­build, gerando e con­fe­rindo cha­ves que serão usa­das durante a comu­ni­ca­ção com os ser­vi­do­res CVS.

Por moti­vos de orga­ni­za­ção, a mai­o­ria dos empa­co­ta­do­res cria uma pasta de tra­ba­lho durante a remessa de paco­tes; eu crio a pasta “cvs”, mas o nome tanto faz:

Como comen­tei no começo, ter o pacote apro­vado é um pro­cesso tra­ba­lhoso e, logo que apro­vado, ele (o pacote) ganha uma pasta (e per­mis­sões) no CVS. O empa­co­ta­dor deve, antes de mais nada, sin­cro­ni­zar sua pasta local com a pasta vir­tual nos ser­vi­do­res do Pro­jeto Fedora:

No meu exem­plo, vou mos­trar o pacote BKChem, um soft­ware para dese­nho de estru­tu­ras mole­cu­la­res em 2D:

Esse script vai bai­xar meu “dire­tó­rio de tra­ba­lho” direto do CVS para o meu disco rígido. Eis o con­teúdo dele:

Observe que há dire­tó­rios para algu­mas ver­sões do Fedora (F-12, F-11, F-10…) e para a ver­são de desen­vol­vi­mento, que cha­ma­mos de Rawhide.

Nova­mente, con­vém lem­brar que o meu RPM já está pronto e eu ape­nas vou remetê-lo para os ser­vi­do­res do Pro­jeto Fedora de modo a deixá-lo dis­po­ní­vel para todos os usuários.

O meu RPM, de fato, não será usado para nada. Cada um dos RPMs dis­po­ni­bi­li­za­dos pelo pro­jeto Fedora é com­pi­lado e assi­nado lá, por isso, em vez de enviar o RPM, eu envio o SRPM (Source RPM), um para cada ver­são ativa do Fedora (atu­al­mente, as ver­sões ati­vas são Fedora 11, 12 e Rawhide).

Nova­mente, a vida fica menos com­pli­cada por­que um script checa e envia o SRPM:

Veja o termo em negrito, ele define para qual “branch” (ver­são do Fedora) esse SRPM irá. No caso, man­dei três vezes: F-11, F-12 e devel.

Veja aqui o upload sendo feito e as men­sa­gens exi­bi­das durante a verificação.

Quando esse pro­cesso ter­mina, você é levado a uma tela do VI onde entra um pequeno log sobre o upload. Veja aqui.

Ao sal­var o log, o pro­cesso de “com­mit” do SRPM ter­mina com mais algu­mas che­ca­gens (que você pode ver aqui).

Pacote SRPM envi­ado, log feito, chega a hora de com­pi­lar o pacote lá no ser­vi­dor. Vou come­çar a com­pi­la­ção para o Fedora 11 e, por isso, entro na pasta F-11:

Sin­cro­nizo nova­mente a pasta, para garan­tir que eu e os ser­vi­do­res esta­mos tra­ba­lhando com as mes­mas ver­sões de arquivos:

e, digito o comando que faz a com­pi­la­ção do meu RPM lá nos ser­vi­do­res do Pro­jeto Fedora:

Essa com­pi­la­ção gera paco­tes para todas as arqui­te­tu­ras dis­po­ní­veis pelo Pro­jeto (veja). Aliás, o soft­ware que com­pila, checa e assina cada RPM chama-se Koji. Todo o pro­cesso de com­pi­la­ção tem que ser feito para cada uma das ver­sões cor­ren­tes do Fedora, lembre-se. Isso sig­ni­fica que, depois de fazer isso para o Fedora 11, fiz, tam­bém para o Fedora 12 e para o devel.

Enfim, depois de pas­sar pelo Koji, o empa­co­ta­dor vai ao Bodhi, que é a inter­face res­pon­sá­vel por puxar os RPMs pron­tos para os repo­si­tó­rios. Nele você define se o pacote vai para “tes­ting” ou “sta­ble”, define se o pacote é uma atu­a­li­za­ção de segu­rança, um con­serto de bug ou uma melho­ria, além, é claro, de mar­car o pacote como neces­si­tando ou não de um reboot após a atualização.

Pronto! Em breve o pacote estará alcan­çando um repo­si­tó­rio perto de você e com um sim­ples “yum ins­tall” você poderá des­fru­tar de um pacote novinho.

Popu­la­rity: 25% [?]

Posts rela­ci­o­na­dos:

1. Como fun­ci­ona: Paco­tes RPM
2. Meu pri­meiro RPM oficial
3. Ainda há ves­tí­gios do Fedora Core
4. O yum down­grade funciona
5. Como fun­ci­ona? — Entra­das nos menus

Tagged as: como funciona?, fedora, trivia