Tutorial de Empaquetamiento: GNU Hello

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 de arriba. La primera letra debe ir en mayúscula para evitar quejas sobre rpmlint.

License describe la licencia del paquete binario resultante usando un identificador de licencia SPDX. Debe seguir las directrices de licenciamiento de Fedora. En la práctica, determinar el valor correcto significa, con frecuencia, inspeccionar las notificaciones de licencias en los archivos fuente individuales. También se puede necesitar preguntar a los desarrolladores upstream para lograr clarificaciones o correcciones. En este tutorial, simplemente tomamos la palabra de la fuente de que la licencia es la GNU Public License, versión 3 o posterior.

URL apunta al sitio web de desarrollo del proyecto.

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

%description can often be copied from upstream README.

%prep contains a shell script for preparing the sources for building. It is often just the single macro %autosetup, which, in this case, simply extracts the source.

%build contains a shell script for the required build steps, such as compiling sources to binaries. GNU Hello uses Autotools as its buildsystem, so building involves running configure and make. Macros %configure and %make_build invoke these commands using Fedora’s compilation flags and other configuration.

%install contains a shell script to copy the results from %build into an initially empty build root directory. As GNU Hello is using Autotools, macro %make_install is used.

%files lists the content of the resulting package. Mostly, the files come from the build root created in the %install, but documentation and license files can also be added directly from the sources. This section is left empty for now, to be filled later.

The %changelog documents the changes in each new package version and release. Changelog data can be displayed by rpm --query --changelog PACKAGE_NAME, which can be useful, for instance, to find out if specific bug and security patches are included. Its value,%autochangelog, also comes from rpmautospec. It populates the changelog from Git commit messages. As we do not have a Git repository, the changelog will be empty.

Lines which are not needed can be commented out with the hash #.

You can find more information in the RPM Reference Manual’s section Spec file format.

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:

Texinfo pages are handled much in the same way as man pages. The directory is defined by the default macro {_infodir}, so the Texinfo manual can be added as follows:

The dir file generated by GNU Hello build script indexes all texinfo pages in your system. Because the installed pages differ among systems, the file cannot be prebuilt and packaged. Instead it needs to be created and updated when the package is installed. The update is automatically performed by rpm triggers in info binary package of texinfo source package.

To prevent from installing the dir file, remove it from the buildroot at the end of the %install section with rm command.

However, GNU Hello build script only generates the dir file if info package is installed during the build. Blindly removing the file would raise an error if the hello package were built on a system without info package. To deal with both cases, delete the file if it exists:

Since our program uses translations and internationalization, we are seeing a lot of undeclared i18n files. The recommended method to declare them is:

Every package must install its license, tagged with %license directive. In GNU Hello’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:

If you carefully read a build output, you can discover lines which mention sed command:

Therefore you need to add this line close to other BuildRequires lines:

Smilarly, studying configure script in the unpackaged sources, which is executed by %configure macro, reveals it’s a /bin/sh script:

Thus you also should record this dependency on bash:

Why on bash? Because /bin/sh program is provided by bash package:

Specifying all used dependencies helps to make the .spec file resilient against changes in the build environment. If e.g. sed package were removed from the environment, this GNU Hello package would fail to build.

The GNU Hello build script, configure has many build options which enables or disables optional features. Their nondefault forms can be listed with --help option:

Some of them are already specified within %configure and %make_build macros. The rest of the options, if they are important for the built package, should be explicitly written in the .spec file to prevent from their sudden and unnoticed changes. Either because a new Hello version changes the default, or because a package which they depend on appears of disappears from the build environment.

Therefore modify %configure invocation in %build section like this:

List the files contained in the package:

You can see that all the files listed in the specfile %files section are included, including the automatically processed locale files. Also, under /usr/lib/.build-id, there is an automatically generated file. It is actually a symlink, mapping a build id to the hello 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 GNU Hello 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: