3.2.3. Modificación de un archivo SPEC original para crear RPMs

Procedimiento

1. Abra la plantilla de salida del archivo ~/rpmbuild/SPECS/<name>.spec proporcionada por la utilidad rpmdev-newspec:

2. Rellene la primera sección del archivo SPEC:

   La primera sección incluye estas directivas que rpmdev-newspec agrupa:

   • Name
   • Version
   • Release

   • Summary

     La dirección Name ya se había especificado como argumento de rpmdev-newspec.

     Establezca el Version para que coincida con la versión de lanzamiento del código fuente.

     El Release se establece automáticamente en 1%{?dist}, que es inicialmente 1. Incrementa el valor inicial cada vez que se actualiza el paquete sin que haya un cambio en la versión upstream Version - como cuando se incluye un parche. Restablezca Release a 1 cuando se produzca una nueva liberación del upstream.

     El sitio web Summary es una breve explicación de una línea de lo que es este software.

3. Rellene las directivas License, URL, y Source0:

   El campo License es la licencia de software asociada con el código fuente de la versión anterior. El formato exacto de cómo etiquetar el License en su archivo SPEC variará dependiendo de las directrices específicas de la distribución de Linux basada en RPM que esté siguiendo.

   Por ejemplo, puede utilizar la GPLv3 .

   El campo URL proporciona la URL del sitio web del software de origen. Por coherencia, utilice la macrovariable RPM de %{name}, y use https://example.com/%{name}.

   El campo Source0 proporciona la URL del código fuente del software de origen. Debe enlazar directamente con la versión específica del software que se está empaquetando. Tenga en cuenta que los ejemplos de URL que se ofrecen en esta documentación incluyen valores codificados que pueden cambiar en el futuro. Del mismo modo, la versión de lanzamiento también puede cambiar. Para simplificar estos posibles cambios futuros, utilice las macros %{name} y %{version}. Al utilizarlas, sólo es necesario actualizar un campo en el archivo SPEC.

4. Rellene las directivas BuildRequires, Requires y BuildArch:

   BuildRequires especifica las dependencias en tiempo de compilación para el paquete.

   Requires especifica las dependencias en tiempo de ejecución del paquete.

   Se trata de un software escrito en un lenguaje de programación interpretado sin extensiones compiladas de forma nativa. Por lo tanto, añade la directiva BuildArch con el valor noarch. Esto le dice a RPM que este paquete no necesita estar ligado a la arquitectura del procesador en el que se construye.

5. Rellene las directivas %description, %prep, %build, %install, %files, y %license:

   Estas directivas pueden ser consideradas como encabezados de sección, ya que son directivas que pueden definir tareas de varias líneas, de varias instrucciones o de secuencias de comandos.

   El scription es una descripción más larga y completa del software que el Summary, que contiene uno o más párrafos.

   La sección %prep especifica cómo preparar el entorno de construcción. Esto normalmente implica la expansión de archivos comprimidos del código fuente, la aplicación de parches y, potencialmente, el análisis de la información proporcionada en el código fuente para su uso en una parte posterior del archivo SPEC. En esta sección se puede utilizar la macro incorporada %setup -q.

   La sección %build especifica cómo construir el software.

   La sección %install contiene instrucciones para rpmbuild sobre cómo instalar el software, una vez construido, en el directorio BUILDROOT.

   Este directorio es un directorio base chroot vacío, que se asemeja al directorio raíz del usuario final. Aquí puede crear cualquier directorio que contenga los archivos instalados. Para crear estos directorios, puede utilizar las macros RPM sin tener que codificar las rutas.

   La sección %files especifica la lista de archivos proporcionados por este RPM y su ubicación completa en el sistema del usuario final.

   Dentro de esta sección, puede indicar el papel de varios archivos utilizando macros incorporadas. Esto es útil para consultar los metadatos del manifiesto del archivo del paquete utilizando el comando[]rpm. Por ejemplo, para indicar que el archivo LICENSE es un archivo de licencia de software, utilice la macro %license.

6. La última sección, %changelog, es una lista de entradas con fecha para cada versión del paquete. Registran los cambios de empaquetado, no los cambios de software. Ejemplos de cambios en el paquete: añadir un parche, cambiar el procedimiento de construcción en la sección %build.

   Siga este formato para la primera línea:

   Comienza con un carácter * seguido de Day-of-Week Month Day Year Name Surname <email> - Version-Release

   Siga este formato para la entrada del cambio real:

   • Cada entrada de modificación puede contener varios elementos, uno por cada modificación.
   • Cada elemento comienza en una nueva línea.
   • Cada elemento comienza con un carácter -.