15.2. Creación de su primer paquete

15.2.1. Metapaquetes o paquetes falsos

Los paquetes falsos y los metapaquetes son similares en que son cascarones vacíos que sólo existen por los efectos que tienen sus metadatos en el sistema de gestión de paquetes.

The purpose of a fake package is to trick dpkg and apt into believing that some package is installed even though it's only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.

Por el otro lado, un metapaquete existe principalmetne como una colección de dependencias, para que su instalación incluya un conjunto de otros paquetes en un solo paso.

Puede crear ambos tipos de paquetes con los programas equivs-control y equivs-build (en el paquete equivs). Si ejecuta equivs-control archivo creará un archivo de cabecera de un paquete Debian que debe editar para que contenga el nombre esperado del paquete, su número de versión, el nombre de su encargado, sus dependencias y su descripción. Puede eliminar todos los demás campos sin un valor predeterminado ya que son opcionales. Los campos Copyright, Changelog, Readme y Extra-Files no son campos estándar en los paquetes Debian, sólo tienen sentido dentro del alcance de equivs-build y no serán mantenidos en las cabeceras del paquete generado.

Ejemplo 15.2. Archivo de cabecera del paquete falso libxml-libxml-perl

Section: perl
Priority: optional
Standards-Version: 3.9.6

Package: libxml-libxml-perl
Version: 2.0116-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Depends: libxml2 (>= 2.7.4)
Architecture: all
Description: Fake package - module manually installed in site_perl
 This is a fake package to let the packaging system
 believe that this Debian package is installed. 
 .
 In fact, the package is not installed since a newer version
 of the module has been manually compiled & installed in the
 site_perl directory.

EL siguiente paso es generar el paquete Debian ejecutando equivs-build archivo. Voilà: se creó el paquete en el directorio actual y lo puede utilizar como cualquier otro paquete Debian.

15.2.2. Simple compendio de archivos

The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package.

→ https://www.debian.org/doc/manuals/maint-guide/

El primer paso es crear un directorio falcot-data-1.0 que contendrá el paquete fuente objetivo. El paquete, lógicamente, se llamará falcot-data y tendrá el número de versión 1.0. El administrador luego ubicará los archivos de documentos en un subdirectorio data. Luego ejecutará dh_make (del paquete dh-make) para agregar los archivos necesarios para el proceso de generación del paquete, que serán almacenados en un subdirectorio debian:

$ cd falcot-data-1.0
$ dh_make --native

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
 [s/i/m/l/k/n] i

Maintainer name : Raphael Hertzog
Email-Address   : hertzog@debian.org
Date            : Fri, 04 Sep 2015 12:09:39 -0400
Package Name    : falcot-data
Version         : 1.0
License         : gpl3
Type of Package : Independent
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the falcot-data Makefiles install into $DESTDIR and not in / .
$

The selected type of package (indep binary) indicates that this source package will generate a single binary package that can be shared across all architectures (Architecture: all). single binary acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (Architecture: any). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.

The multiple binary type corresponds to a source package leading to several binary packages. A particular case, library, is useful for shared libraries, since they need to follow strict packaging rules. In a similar fashion, kernel module or kernel patch should be restricted to packages containing kernel modules.

SUGERENCIA Nombre y dirección de correo del encargado

Most of the programs involved in package maintenance will look for your name and email address in the DEBFULLNAME and DEBEMAIL or EMAIL environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is bash, it is a simple matter of adding the following two lines in your ~/.bashrc file (you will obviously replace the values with more relevant ones!):

export EMAIL="hertzog@debian.org"
export DEBFULLNAME="Raphael Hertzog"

El programa dh_make crea un subdirectorio debian con muchos archivos. Algunos son necesarios, en particular rules, control, changelog y copyright. Los archivos con extensión .ex son archivos de ejemplo que puede utilizar modificándolos (y eliminando la extensión) cuando necesite. Si no los necesita, le recomendamos eliminarlos. Debe mantener el archivo compat ya que es necesario para que funcione correctamente la suite de programas debhelper (todos los que comienzan con el prefijo dh_) que son utilizados en varias etapas del proceso de creación del paquete.

The copyright file must contain information about the authors of the documents included in the package, and the related license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from unstable to internal is enough. The control file was also updated: the Section field has been changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with iceweasel | www-browser so as to ensure the availability of a web browser able to display the documents in the package.

Ejemplo 15.3. El archivo control

Source: falcot-data
Section: misc
Priority: optional
Maintainer: Raphael Hertzog <hertzog@debian.org>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.5

Package: falcot-data
Architecture: all
Depends: iceweasel | www-browser, ${misc:Depends}
Description: Internal Falcot Corp Documentation
 This package provides several documents describing the internal
 structure at Falcot Corp.  This includes:
  - organization diagram
  - contacts for each department.
 .
 These documents MUST NOT leave the company.
 Their use is INTERNAL ONLY.

Ejemplo 15.4. El archivo changelog

falcot-data (1.0) internal; urgency=low

  * Initial Release.
  * Let's start with few documents:
    - internal company structure;
    - contacts for each department.

 -- Raphael Hertzog <hertzog@debian.org>  Fri, 04 Sep 2015 12:09:39 -0400

Ejemplo 15.5. El archivo copyright

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: falcot-data

Files: *
Copyright: 2004-2015 Falcot Corp
License: 
 All rights reserved.

VOLVER A LOS CIMIENTOS El archivo Makefile

Un archivo Makefile es un script utilizado por el programa make; describe las reglas para crear un conjunto de archivos desde otros en un árbol de dependencias (por ejemplo, podemos compilar un programa desde un conjunto de archivos fuente). El archivo Makefile describe estas reglas en el siguiente formato:

objetivo: fuente1 fuente 2 ...
        orden1
        orden2

La interpretación de esta regla es como sigue: si uno de los archivos fuente* es más reciente que el archivo objetivo, entonces es necesario generar el objetivo utilizando orden1 y orden2.

Sepa que las líneas de órdenes deben comenzar con un carácter de tabulación; también debe saber que cuando una línea de órdenes comienza con un carácater de guión (-), si éste falla no interrumpirá todo el proceso.

El archivo rules generalmente contiene un conjunto de reglas utilizadas para configurar, compilar e instalar el software en un subdirectorio dedicado (cuyo nombre coincide con el del paquete binario generado). Luego se incluye el contenido de este subdirectorio en el compendio del paquete Debian como si fuera la raíz del sistema de archivos. En nuestro caso, se instalarán los archivos en el subdirectorio debian/falcot-data/usr/share/falcot-data/ para que el paquete generado despliegue los archivos en /usr/share/falcot-data/. Se utiliza el archivo rules como si fuera un archivo Makefile, con unos pocos objetivos estándar (incluyendo clean y binary, utilizados para limpiar el directorio fuente y generar el paquete binario respectivamente).

Si bien este archivo es el corazón del proceso, cada vez más contiene sólo el mínimo indispensable para ejecutar un conjunto estándar de programas que provee la herramienta debhelper. Tal es el caso de los archivos generados por dh_make. Para instalar nuestros archivos simplemente configuraríamos el comportamiento de dh_install creando el siguiente archivo debian/falcot-data.install:

data/* usr/share/falcot-data/

At this point, the package can be created. We will however add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a falcot-data.desktop file and get it installed in /usr/share/applications by adding a second line to debian/falcot-data.install.

Ejemplo 15.6. The falcot-data.desktop file

[Desktop Entry]
Name=Internal Falcot Corp Documentation
Comment=Starts a browser to read the documentation
Exec=x-www-browser /usr/share/falcot-data/index.html
Terminal=false
Type=Application
Categories=Documentation;

The updated debian/falcot-data.install looks like this:

data/* usr/share/falcot-data/
falcot-data.desktop usr/share/applications/

Ahora nuestro paquete fuente está listo. Todo lo que falta es generar el paquete binario con el mismo método que utilizamos para recompilar paquetes: ejecutaremos dpkg-buildpackage -us -uc desde el directorio falcot-data-1.0.