3.2.3. Modificando um arquivo SPEC original para criar RPMs

Procedimento

1. Abra o modelo de saída do arquivo ~/rpmbuild/SPECS/<name>.spec fornecido pelo utilitário rpmdev-newspec:

2. Povoar a primeira seção do arquivo da SPEC:

   A primeira seção inclui estas diretrizes que foram agrupadas em rpmdev-newspec:

   • Name
   • Version
   • Release

   • Summary

     O Name já foi especificado como um argumento para rpmdev-newspec.

     Defina o Version para combinar com a versão de lançamento upstream do código fonte.

     O Release é automaticamente ajustado para 1%{?dist}, que é inicialmente 1. Aumente o valor inicial sempre que atualizar o pacote sem uma mudança no lançamento a montante Version - como quando se inclui um patch. Redefinir Release para 1 quando um novo lançamento upstream acontecer.

     O Summary é uma breve explicação de uma linha do que é este software.

3. Popular as diretrizes License, URL, e Source0:

   O campo License é a Licença de Software associada com o código fonte da versão upstream. O formato exato de como rotular o License em seu arquivo SPEC variará dependendo de quais diretrizes específicas de distribuição Linux baseadas em RPM você está seguindo.

   Por exemplo, você pode usar a GPLv3 .

   O campo URL fornece o URL para o site do software upstream. Para maior consistência, utilize a macro variável RPM de %{name}, e use o campo https://example.com/%{name}.

   O campo Source0 fornece o URL para o código fonte do software upstream. Ele deve ser ligado diretamente à versão específica do software que está sendo empacotado. Note que as URLs de exemplo dadas nesta documentação incluem valores codificados que são possíveis sujeitos a mudanças no futuro. Da mesma forma, a versão de lançamento também pode mudar. Para simplificar estas possíveis mudanças futuras, use as macros %{name} e %{version}. Ao usá-las, você precisa atualizar apenas um campo no arquivo SPEC.

4. Povoar as diretrizes BuildRequires, Requires e BuildArch:

   BuildRequires especifica as dependências de tempo de construção para o pacote.

   Requires especifica as dependências de tempo de execução para o pacote.

   Este é um software escrito em uma linguagem de programação interpretada, sem extensões compiladas nativamente. Portanto, acrescente a diretiva BuildArch com o valor noarch. Isto diz ao RPM que este pacote não precisa estar vinculado à arquitetura do processador sobre o qual é construído.

5. Povoar as diretrizes %description, %prep, %build, %install, %files, e %license:

   Essas diretrizes podem ser consideradas como títulos de seção, pois são diretrizes que podem definir tarefas de múltiplas linhas, multi-instrução ou tarefas com scripts a serem realizadas.

   O scription é uma descrição mais longa e completa do software do que Summary, contendo um ou mais parágrafos.

   A seção %prep especifica como preparar o ambiente de construção. Isto geralmente envolve a expansão de arquivos comprimidos do código fonte, aplicação de correções e, potencialmente, análise das informações fornecidas no código fonte para uso em uma parte posterior do arquivo SPEC. Nesta seção, você pode usar a macro %setup -q embutida.

   A seção %build especifica como construir o software.

   A seção %install contém instruções para rpmbuild sobre como instalar o software, uma vez que tenha sido construído, no diretório BUILDROOT.

   Este diretório é um diretório de base chroot vazio, que se assemelha ao diretório raiz do usuário final. Aqui você pode criar quaisquer diretórios que contenham os arquivos instalados. Para criar tais diretórios, você pode usar as macros RPM sem ter que codificar os caminhos de forma rígida.

   A seção %files especifica a lista de arquivos fornecidos por esta RPM e sua localização completa no sistema do usuário final.

   Dentro desta seção, você pode indicar o papel de vários arquivos usando macros embutidos. Isto é útil para consultar os metadados do manifesto do arquivo de pacotes usando o comando[]rpm. Por exemplo, para indicar que o arquivo LICENSE é um arquivo de licença de software, use a macro %license.

6. A última seção, %changelog, é uma lista de entradas marcadas com dados para cada Versão-Release do pacote. Eles registram as mudanças de embalagem, não as mudanças de software. Exemplos de mudanças de embalagem: adicionar um patch, mudar o procedimento de construção na seção %build.

   Siga este formato para a primeira linha:

   Comece com um caracter * seguido por Day-of-Week Month Day Year Name Surname <email> - Version-Release

   Siga este formato para a entrada da mudança propriamente dita:

   • Cada entrada de mudança pode conter vários itens, um para cada mudança.
   • Cada item começa em uma nova linha.
   • Cada item começa com um caracter -.