Product SiteDocumentation Site

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.
El propósito de un paquete falso es engañar a dpkg y apt para que crean que un paquete está instalado. Esto permite satisfacer las dependencias de un paquete cuando se instaló el software correspondiente fuera del alcance del sistema de paquetes. Este método funciona, pero debería evitarlo siempre que sea posible ya que no hay garantías que el software instalado manualmente se comporta exactamente de la misma forma que el paquete correspondiente y que otros paquetes que dependan de él funcionarán correctamente.
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

Sección: perl
Prioridad: optional
Versión-Standards: 3.9.6

Paquete: libxml-libxml-perl
Versión: 2.0116-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Dependencias: libxml2 (>= 2.7.4)
Arquitectura: all
Description: Paquete falso - módulo instalado manualmente en site_perl
 Se trata de un paquete falso que hace creer al sistema de 
 empaquetado que este paquete Debian está instalado.
 .
 De hecho, el paquete no se instala si una version más moderna
 del módulo se ha compilado manualmente e instalado en el
 directorio site_perl.
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

Los administradores de Falcot Corp necesitaron crear un paquete Debian para facilitar el despliegue de un conjunto de documentos en una gran cantidad de equipos. El administrador a cargo de esta tarea primero leyó la «Guía del nuevo desarrollador de Debian» y luego comenzó a trabajar en su primer paquete.
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 / .
$
El tipo de paquete seleccionado (binario independiente: «indep binary») indica que este paquete fuente generará sólo un paquete binario que puede ser compartido entre todas las arquitecturas (Architecture: all. Binario único («single binary») es lo contrario y generará sólo un paquete binario que depende de la arquitectura objetivo (Architecture: any). En este caso, esta primera opción es la más relevante, ya que el paquete sólo contiene documentos y ningún programa binario, por lo que se lo puede utilizar de la misma forma en equipos de cualquier arquitectura.
El tipo binario múltiple («multiple binary») corresponde a un paquete fuente que generará varios paquetes binarios. Un caso particular, biblioteca («library»), es útil para bibliotecas compartidas ya que necesitan seguir reglas de empaquetado estrictas. De forma similar, debería restringir el uso de módulo de núcleo («kernel module») o parche del núcleo («kernel patch») a paquetes que contengan módulos de núcleo.
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.
El archivo copyright debe contener la información sobre los autores de los documentos incluidos en el paquete y las licencias relacionadas. En nuestro caso, éstos son documentos internos y su uso está restringido a la empresa Falcot Corp. El archivo changelog predeterminado generalmente es el apropiado; Es sufuciente reemplazar «Initial release» con una explicación más detallada y cambiar la distribución de unstable a internal. También se actualizó el archivo control: se modificó el campo Sección a misc y se eliminaron los campos Homepage, Vcs-Git y Vcs-Browser. Se completaron los campos de Depends con iceweasel | www-browser para asegurar que exista un navegador web disponible capaz de mostrar los documentos en el paquete.

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

Paquate: falcot-data
Arquitectura: all
Dependencias: iceweasel | www-browser, ${misc:Depends}
Descripción: Documentación interna de Falcot Corp
 Este paquete proporciona varios documentos que decriben la estructura 
 interna de Falcot Corp.  Incluye:
  - diagrama de la organización
  - contactos para cada departamento.
 .
 Estos documentos NO DEBEN salir de la empresa.
 Solo para USO INTERNO.

Ejemplo 15.4. El archivo changelog

falcot-data (1.0) internal; urgency=low

  * Entrega inicial.
  * Empecemos con unos pocos documentos:
    - estructura interna de la compañía;
    - contactos para cada departamento.

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

Ejemplo 15.5. El archivo copyright

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

Ficheros: *
Copyright: 2004-2015 Falcot Corp
Licencia: 
 Todos los derechos reservados.
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/
En este punto, podemos crear el paquete. Sin embargo, agregaremos una capa de pintura. Debido a que los administradores desean que se pueda acceder fácilmente a los documentos desde los menú de los entornos gráficos de escritorio, añadiremos un fichero falcot-data.desktop y lo instalaremos en /usr/share/applications agregando una segunda línea a debian/falcot-data.install.

Ejemplo 15.6. El archivo falcot-data.desktop

[Desktop Entry]
Name=Documentaciónn Interna Falcot Corp
Comment=Inicia un navegador para leer la documentación
Exec=x-www-browser /usr/share/falcot-data/index.html
Terminal=false
Type=Application
Categories=Documentation;
El debian/falcot-data.install actualizado se parece a este:
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.