Muitas pessoas (pelo menos assim acredito), gostariam de aprender a receita para gerar um RPM de seu software favorito; a regra de ouro se você usa uma distribuição que gerencia pacotes é “evite, sempre que possível, instalar softwares que não sejam empacotados para o seu linux”, mas, se você usa Fedora ou alguma dessas outras distros “linha dura” pode acabar ficando sem aquele programinha que você tanto gosta.
Para evitar essa tragédia, vou aproveitar o post de hoje para ensinar em passos simples como empacotar um software qualquer em RPM.
Busquei ao acaso um software qualquer que ainda não exista nos repositórios do Fedora, um exemplo bem simples é o FMIT (Free Music Instrument Tuner for Linux). O software é pequeno e pode ser instalado da maneira clássica (./configure, make, make install), por isso é perfeito para o nosso exemplo.
Primeiro passo: conseguindo o código fonte
Vá ao site do FMIT baixar o código fonte:
Com o código fonte em mãos, descompacte-o e vá dar uma olhada no que ele pede para compilar sem problemas. Se você está acostumado a instalar softwares direto pelo código fonte vai se lembrar de que o ./configure checa e avisa quais os componentes necessários para uma compilação (e instalação) correta.
Já adianto que o FMIT necessita alsa-lib-devel, freeglut-devel, fftw3-devel, jack-audio-connection-kit-devel, portaudio-devel e qt3-devel para compilar direito e também alsa-lib, fftw3, freeglut, jack-audio-connection-kit para rodar com todas as funcionalidades.
Instalar um software a partir do código fonte consiste mesmo em juntar todas as peças necessárias para poder compilar e isso exige paciência aliada a algumas habilidades detetivescas.
Segundo passo: criando o ambiente certo
Já baixamos o código fonte e ficamos familiarizados com o que nosso software vai depender para ser compilado. O próximo passo é preparar seu sistema para gerar RPMs. Instalar o ambiente de desenvolvimento é muito simples:
$ su -c 'yum install rpmdevtools'
Isso instala os softwares necessários e
$ rpmdev-setuptree
Que vai gerar as pastas e as macros usadas no desenvolvimento.
O local de desenvolvimento, você vai reparar, fica dentro de uma pasta chamada rpmbuild (~/rpmbuild). Nunca, nunca mesmo, em hipótese alguma, faça RPMs como root porque isso pode dar “permissões demais” aos seus pacotes e não queremos isso, certo?
Dentro de ~/rpmbuild há 5 pastas: SRPMS, RPMS, SPECS, BUILD, SOURCES;
- A pasta SOURCES é onde você deve jogar o código fonte do programa que vai empacotar. Não se preocupe em descompactá-lo;
- Na pasta SPECS você vai criar um script que é próprio para fazer RPMs chamado “arquivo de especificação”. Nele escreveremos todos os dados do RPM como nome, versão, descrição etc. Geralmente ele recebe o nome do programa a ser empacotado com a extensão .spec, portanto, como vamos empacotar o FMIT, ele deve se chamar fmit.spec;
- Na pasta BUILD ocorre o processo de compilação. Aqui é onde é feito o trabalho sujo pelo compilador. O seu código fonte é automaticamente descompactado aqui, checado, compilado e empacotado. Pense nessa pasta como a “linha de produção” dos seus pacotes.
- Em RPMS são jogados os pacotes prontos. Basta vir aqui e instalar as crianças. =)
- SRPMS também contém RPMs, mas não do tipo que vem com um executável. O SRPM é apenas o código fonte do seu RPM. Com um SRPM, qualquer um é capaz de reproduzir o seu RPM sem nenhum esforço. Dentro dele temos o código fonte do software, o seu arquivo .spec ou qualquer outra coisa que você tenha colocado em seu pacote.
Terceiro passo: Criando o seu arquivo .spec
A parte mais chata é essa. Um arquivo .spec tem partes muito bem definidas que precisam ser levadas à risca para gerar um bom pacote, mas não se assuste, hoje em dia há muita coisa já pronta ou automatizada para nos ajudar. Por exemplo, você pode usar o VI/VIM para gerar um arquivo .spec genérico e “oco” para você:
Entre na pasta dos arquivos .spec
$ cd ~/rpmbuild/SPECS
Mande o VI/VIM criar o arquivo .spec vazio:
$ vim fmit.spec
Reparou que “automagicamente” o nosso arquivo de especificação já veio com os campos a preencher? Alguns campos são óbvios (outros nem tanto). Senão, vejamos:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| Name: # O nome do programa
Version: # A versão do programa
Release: 1%{?dist} # A release do pacote. Aqui vem aquela parte -1.fc11, -2.fc11...
Summary: # Curta descrição do software
Group: # A qual grupo pertence o software? Por exemplo: Applications/Multimedia
License: # Qual a licensa vigente sobre o software? Por exemplo, GPL, MIT...
URL: # Site do desenvolvimento upstream
Source0: # O link do código fonte.
BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) # Troque esta parte por %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: # Todos os pacotes necessários para a compilação.
Requires: # Todos os pacotes que são “dependências” para o seu software rodar bem.
%description # Uma descrição mais completa do seu software
%prep # Nesta seção o seu código fonte é “tratado”. Descompacta-se, aplica-se patches...
%setup -q
%build # Aqui vem, automática a parte do ./configure e do make
%configure
make %{?_smp_mflags}
%install # Instalação do software
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean # Limpeza do seu “espaço de trabalho” para garantir que esteja limpo se precisar usar de novo.
rm -rf $RPM_BUILD_ROOT
%files # Diga nesta seção quais os arquivos presentes no seu RPM, assim, ao desinstalá-lo, não sobrará nenhum “lixo”.
%defattr(-,root,root,-)
%doc
%changelog # Para manter um histórico do seu trabalho |
Quarto passo: preencendo seu arquivo .spec
Vamos preencher o nosso spec passo a passo. A primeira seção é bem simples, são apenas informações gerais:
1
2
3
4
5
6
7
8
9
10
| Name: fmit
Version: 0.97.7
Release: 1%{?dist}
Summary: Free Music Instrument Tuner for Linux
Group: Applications/Multimedia
License: GPLv2
URL: http://home.gna.org/fmit/index.html
Source0: http://download.gna.org/fmit/fmit-0.97.7.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) |
Na segunda seção, colocamos as dependências para compilar e para funcionar:
BuildRequires: alsa-lib-devel >= 0.9
BuildRequires: freeglut-devel
BuildRequires: fftw3-devel
BuildRequires: jack-audio-connection-kit-devel >= 0.103
BuildRequires: portaudio-devel
BuildRequires: qt3-devel
Requires: alsa-lib >= 0.9
Requires: fftw3
Requires: freeglut
Requires: jack-audio-connection-kit >= 0.103
Na terceira seção, uma explicação mais detalhada sobre o software:
1
2
| %description
Free Music Instrument Tuner for Linux, bla, bla bla... |
Agora, na quarta seção, um detalhe importante: o FMIT é um software muito simples que pode ser compilado com ./configure, make e make install sem precisar de mais nenhum parâmetro adicional, por isso, não precisa mexer em nada nessas partes aqui:
1
2
3
4
5
6
7
8
9
10
11
12
13
| %prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT |
É claro que se nosso compilador precisasse de alguma instrução extra haveria mais coisas a fazer na quarta seção, mas isso não vem ao caso agora; quem sabe num próximo artigo?
A quinta seção vai catalogar tudo que há no seu RPM para instalação/desinstalação:
1
2
| %files
%defattr(-,root,root,-) |
1
| %doc AUTHORS COPYING ChangeLog TODO |
Liste tudo que pode ser considerado documentação no seu pacote
Você se lembra dessa parte? “%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} –n)” Isso gerou, do lado da pasta BUILD uma nova pasta chamada BUILDROOT. Essa novas pasta é uma pasta “fake” onde o software vai se instalar pensando que está sendo instalado no sistema. Ela tem capacidade de imitar todas as pastas da pasta / de modo a garantir que o software consiga encontrar os lugares devidos à sua “acomodação”. Você deve olhar nessa pasta para descobrir quais arquivos precisam ser “declarados”
1
2
3
4
| %{_bindir}/fmit # %{_bindir} significa /usr/bin
%{_datadir}/fmit # %{_datadir} significa /usr/share
%{_datadir}/applications/fmit.desktop
%{_libdir}/*.a # %{_libdir} significa /usr/lib |
Na sexta seção, mantenha um histórico do seu trabalho:
1
2
3
| %changelog
* Sun May 10 2009 Henrique "LonelySpooky" Junior - 0.97.7-1
- Initial package |
Quinto passo: gerando o RPM
A etapa mais fácil. Mande o rpmbuild gerar seu rpm:
$ rpmbuild -ba ~/rpmbuil/SPECS/fmit.spec
Se tudo correr bem você vai ver as mensagens de compilação e, ao fim, as seguintes linhas:
Gravou: /home/lonely/rpmbuild/SRPMS/fmit-0.97.7-1.fc11.src.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-0.97.7-1.fc11.i586.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-debuginfo-0.97.7-1.fc11.i586.rpm
Como prometido, na pasta RPMS estará seu rpm do fmit e um pacotinho com informações de debug que você não precisa.
Este é um exemplo tão genérico quanto possível e tentei apresentar de forma simples como proceder, mas, convém avisar, gerar RPMs varia muito dependendo da linguagem de programação e mesmo um pacote simples como esse pode ser feito de forma mais “elegante”. Em todo caso, espero que tenha matado a curiosidade de alguns ou dado um “empurrãozinho” em quem deseja começar no empacotamento.
Leituras recomendadas
Comentários