Tutorial de Empaquetamiento 1: banner

Version contiene el número de versión del software empaquetado.

Release numera las actualizaciones del fichero de especificaciones, las reconstrucciones del paquete y otro trabajo dentro de Fedora. El valor usado aquí, %autorelease, es parte de rpmautospec, que es el recomendado para los paquetes de Fedora. Se vincula Release al histórico Git del paquete. Como no tenemos un repositorio Git, %autorelease se evaluará al valor predeterminado de 1.

Con frecuencia, Summary puede ser copiado del README upstream. La primera letra debe ir en mayúscula para evitar quejas sobre rpmlint.

License describe la licencia del paquete binario resultante utilizando el identificador de licencia SPDX. Debe seguir las directrices de licencia. En la practica, determinar el valor correcto a menudo significa inspeccionar las notificaciones de licencias en los archivos fuente individuales. También puede ser necesario pedir a los desarrolladores upstream clarificaciones y correcciones. En este tutorial, simplemente tomamos la palabra de upstream de que la licencia es GNU Public License, versión 2.

URL apunta al sitio web del proyecto upstream, que en este caso es la página de repositorios GitHub.

Source define las fuentes upstream usadas cuando se construye el paquete. Usualmente, como en este caso, es una url apuntando a un archivo comprimido liberado por upstream, pero también puede ser un archivo local. Puede haber múltiples etiquetas Source si es necesario.

%description puede ser copiado a menudo del README de upstream.

%prep contiene un script de shell para preparar las fuentes para la construcción. A menudo es solo la macro %autosetup, la cual, en este caso, simplemente extrae la fuente.

%build contiene un script de shell para los pasos requeridos de construcción, como compilar fuentes en binarios. Dado que el sistema de construcción de banner es Autotools, la construcción implica ejecutar configure y make. Las macros %configure y %make_build invocan estos comandos utilizando los indicadores de compilación de Fedora y otra configuración.

%install contiene un script de shell para copiar los resultados de %build en un directorio, inicialmente vacío, build root. Como banner está utilizando Autotools, se utiliza la macro %make_install.

%files lista el contenido del paquete resultante. Mayormente, los archivos vienen del build root creado en %install, pero la documentación y los archivos de licencia se pueden añadir directamente desde las fuentes. Esta sección se deja vacía por ahora, para rellenarse más tarde.

%changelog documenta los cambios en cada nueva versión y lanzamiento del paquete. Los datos del registro de cambios se pueden visualizar con rpm --query --changelog PACKAGE_NAME, que puede ser útil, por ejemplo, para encontrar si se han incluido la corrección a un error específico y parches de seguridad. Su valor, %autochangelog, también viene de rpmautospec. Completa el registro de cambios a partir de mensajes de confirmación de Git. Como no tenemos repositorio Git, el registro de cambios estará vacío.

Las líneas que no son necesarias se pueden comentar con almohadillas #.

Puede encontrar más información en la sección Formato del archivo de especificaciones del Manual de Referencia RPM.

This is the executable binary program. /usr/bin, like many other system directories, have a default rpm macro defined. The macros should always be used when available, so the executable is listed in %files as follows:

The Packaging Guidelines have a dedicated section for Manpages. Following its instructions, manpages are list as follows:

At this point, mockbuild completes successfully, but there are still more files that we should add to the package.

Every package must install its license, tagged with %license directive. In banner’s case, as well as for many other projects, the license file is located at the source tarball’s top level, and perhaps not copied to the buildroot during installation at all. Regardless, it can be installed to the standard license directory by using a relative path:

Often, package sources contain documentation that could be useful for the end users as well. These can be installed and marked as documentation with the %doc directive. Similarly to %license, relative paths can be used to include files directly from the source tarball rather than from the buildroot:

List the files contained in the package:

You can see that all the files listed in the specfile %files section are included. Also, under /usr/lib/.build-id, there is an automatically generated file. It is actually a symlink, mapping a build id to the banner binary for debugging purposes.

List the package’s runtime dependencies with the following command:

To check which packages in Fedora repositories provide these dependencies, you can use dnf repoquery:

You will see that the only dependency of banner is glibc, which provides symbols in libc.so.6 as well as rtld(GNU_HASH).

The rpmlib requires are special. These specify various rpm features used in the rpm package itself, constraining the version of rpm that can be used to install the package.

Conversely, to check what capabilities the package provides, you can do:

The provides of this package are very simple. It simply provides its own name, in plain and architecture specific forms.

As a final check, the package can be installed and ran:

To clean up your system, undo the installation: