
               Guía del nuevo desarrollador de Debian


---------------------------------------------------------------------
                                  
                             Josip Rodin

              contenidos originales <joy-mg@debian.org>

                             Osamu Aoki

             contenidos actualizados <osamu@debian.org>

Javier Fernández-Sanguino Peña

<jfs@debian.org>

David Martínez

<ender@debian.org>

Ana Beatriz Guerrero López

<ana@debian.org>

Francisco Javier Cuadrado

<fcocuadrado@gmail.com>

Innocent De Marchi

<tangram.peces@gmail.com>

                        versión 1.2.53build1

---------------------------------------------------------------------

Copyright © 1998-2002 Josip Rodin

Copyright © 2005-2015 Osamu Aoki

Copyright © 2010 Craig Small

Copyright © 2010 Raphaël Hertzog

    This document may be used under the terms of the GNU General
    Public License version 2 or higher.

    Este documento se ha escrito usando estos dos documentos como
    ejemplo:

      * «Making a Debian Package (AKA the Debmake Manual)», copyright
        © 1997 Jaldhar Vyas.

      * «The New-Maintainer's Debian Packaging Howto», copyright ©
        1997 Will Lowe.

        The rewrite of this tutorial document with updated contents
        and more practical examples is available as "Guide for Debian
        Maintainers". Please use this new tutorial as the primary
        tutorial document.

2025-12-16 19:30:30 UTC

---------------------------------------------------------------------

Tabla de contenidos

1. Empezando «de la forma correcta».
    1.1. Dinamismo social en Debian
    1.2. Programas necesarios para el desarrollo
    1.3. Documentos necesarios para el desarrollo
    1.4. Dónde pedir ayuda
2. Primeros pasos
    2.1. Plan de trabajo para la construcción de paquetes Debian
    2.2. Elige el programa
    2.3. Obtén el programa y pruébalo
    2.4. Métodos de compilación simple
    2.5. Métodos de compilación portables populares
    2.6. Nombre del paquete y versión
    2.7. Configurar dh_make
    2.8. Paquete no nativo Debian inicial
3. Modificar las fuentes
    3.1. Configurar quilt
    3.2. Corregir un error en el código fuente
    3.3. Instalación de los archivos en su destino
    3.4. Diferencias en las bibliotecas
4. Archivos necesarios en el directorio debian
    4.1. El archivo control
    4.2. El archivo copyright
    4.3. El archivo changelog
    4.4. El archivo rules
        4.4.1. Objetivos del archivo rules
        4.4.2. Archivo rules predeterminado
        4.4.3. Personalización del archivo rules
5. Otros ficheros en el directorio debian.
    5.1. Archivo README.Debian (LÉEME.debian)
    5.2. Archivo compat
    5.3. Archivo conffiles
    5.4. Archivos nombre_del_paquete.cron.*
    5.5. Archivo dirs
    5.6. Archivo nombre_del_paquete.doc-base
    5.7. Archivo docs
    5.8. Archivo emacsen-*
    5.9. Archivo nombre_del_paquete.examples
    5.10. Archivos nombre_del_paquete.init y nombre_del_paquete
    .default
    5.11. Archivo install
    5.12. Archivo nombre_del_paquete.info
    5.13. Archivo nombre_del_paquete.links
    5.14. Archivos {nombre_del_paquete.source/} lintian-overrides
    5.15. Archivos manpage.*
        5.15.1. Archivo manpage.1.ex
        5.15.2. Archivo manpage.sgml.ex
        5.15.3. Archivo manpage.xml.ex
    5.16. Archivo nombre_del_paquete.manpages
    5.17. Archivo NEWS
    5.18. Archivos {pre,post}{inst,rm}
    5.19. Archivo nombre_del_paquete.symbols
    5.20. Archivo TODO
    5.21. Archivo watch
    5.22. Archivo source/format
    5.23. Archivo source/local-options
    5.24. Archivo source/options
    5.25. Archivos patches/*
6. Construcción del paquete
    6.1. (Re)construcción completa
    6.2. Autobuilder
    6.3. La orden debuild
    6.4. El paquete pbuilder
    6.5. git-buildpackage command and similar
    6.6. Reconstrucción rápida
    6.7. Jerarquía de órdenes
7. Comprobación del paquete en busca de fallos
    7.1. Cambios sospechosos
    7.2. Comprobación de la instalación del paquete
    7.3. Comprobación de los guiones del desarrollador («maintainer
    scripts»)
    7.4. El paquete lintian
    7.5. La orden debc
    7.6. La orden debdiff
    7.7. La orden interdiff
    7.8. La orden mc
8. Actualizar el paquete
    8.1. Nueva revisión Debian del paquete
    8.2. Inspección de una nueva versión del autor
    8.3. Nueva versión del programa fuente
    8.4. Actualizar el formato del paquete
    8.5. Conversión a UTF-8
    8.6. Recordatorio para actualizar paquetes
9. Enviar el paquete
    9.1. Enviar al repositorio de Debian
    9.2. Incluir orig.tar.gz para la transferencia del paquete al
    repositorio.
    9.3. Envíos discontinuados
A. Técnicas avanzadas
    A.1. Bibliotecas compartidas
    A.2. Gestionando debian/package.symbols
    A.3. Varias arquitecturas
    A.4. Construcción de un paquete de biblioteca compartida
    A.5. Paquete nativo Debian

Capítulo 1. Empezando «de la forma correcta».

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Este documento tratará de describir cómo se construye un paquete
    Debian GNU/Linux para el usuario común de Debian y para futuros
    desarrolladores en un lenguaje informal, y con multitud de
    ejemplos. Hay un antiguo dicho romano que dice, «Longum iter est
    per preaecepta, breve et efficax per exempla!» (¡Es un largo
    camino con las reglas, pero corto y eficiente con ejemplos!).

    This document is made available for the Debian Buster release
    since this offers many translations. This document will be
    dropped in the following releases since contents are getting
    outdated. ^[1]

    Una de las cosas que hace a Debian una de las distribuciones más
    importantes del mercado es su sistema de paquetes. Aunque hay una
    gran cantidad de programas disponibles en forma de paquetes de
    Debian, algunas veces necesitarás instalar programas que no están
    disponible en este formato. Puede que te preguntes cómo hacer tus
    propios paquetes y que pienses que quizás ésta es una tarea
    demasiado difícil. Bueno, si eres un principiante en GNU/Linux,
    sí es duro, pero si eres un novato, no deberías estar leyendo
    esto ahora mismo. :-) Necesitas saber algo sobre programación en
    Unix, pero, desde luego, no tienes que ser un maestro ^[2].

    Sin embargo, hay una cosa que es verdad: para construir y
    mantener paquetes Debian adecuadamente, necesitarás muchas horas.
    Para que nuestro sistema trabaje sin errores, nuestros
    desarrolladores necesitan ser técnicamente competentes y
    concienzudos.

    If you need some help with packaging, please read Sección 1.4,
    “Dónde pedir ayuda”.

    Las nuevas versiones de este documento están en http://
    www.debian.org/doc/maint-guide/ y en el paquete maint-guide. Las
    traducciones pueden obtenerse en paquetes como maint-guide-es.
    Debe tenerse presente que las traducciones pueden estar
    desactualizadas.

    Como se trata de un tutorial, he optado por explicar cada paso
    detalladamente en algunos temas importantes. Algunas
    explicaciones pueden parecerte irrelevantes. Te ruego que seas
    paciente. También he omitido intencionalmente algunos casos
    extremos y algunos aspectos sólo se mencionan con la intención de
    que el documento sea sencillo.

1.1. Dinamismo social en Debian

    Aquí explico mis observaciones sobre la dinámica social en
    Debian. Espero que esto te preparará para la interacción con
    Debian:

      * Todos somos voluntarios.

          + No puedes imponer a los demás lo que debe hacerse.

          + Debes estar motivado para hacer las cosas por ti mismo.

      * La cooperación amistosa es la fuerza motriz.

          + Tu contribución no debe estresar a los demás.

          + Tu contribución es valiosa sólo cuando los demás te lo
            agradecen..
   
      * Debian no es la escuela donde recibir atención automática de
        los profesores.

          + Debes ser capaz de aprender muchas cosas por ti mismo.

          + La atención por parte de otros voluntarios es un recurso
            muy escaso.

      * Debian está mejorando constantemente.

          + Se espera que generes paquetes de alta calidad.

          + Debes adaptarte al cambio.

    Se utilizan distintos nombres para referirse a los roles dentro
    de Debian:

      * autor original («upstream author»): para referirse a la
        persona que ha escrito el código original del programa (o la
        documentación original en el caso de paquetes de
        documentación).

      * desarrollador original («upstream maintainer»): la persona
        que se encarga de mantener el programa (el código fuente) en
        la actualidad.

      * empaquetador (desarrollador) («maintainer»): la persona que
        se encarga de construir y mantener actualizados paquetes para
        Debian (N. del t.: hay una cierta ambigüedad en la traducción
        de «maintainer» por desarrollador puesto que se puede
        confundir con la traducción de «Debian Developer»,
        desarrollador que pertenece al proyecto, y de «upstream
        maintainer», desarrollador del programa original).
   
      * patrocinador («sponsor»): la persona (que debe ser un DD o
        DM, véase más adelante) que transfiere los paquetes
        elaborados por el desarrollador al archivo de paquetes de
        Debian (al repositorio de Debian) después de comprobar que el
        paquete cumple los requisitos exigidos.

      * mentor: la persona que ayuda a los desarrolladores
        principiantes a iniciarse en la construcción y mantenimiento
        de paquetes.

      * desarrollador de Debian (DD) («Debian Developer»): la persona
        que es miembro de Debian. Tiene permiso total para transferir
        paquetes al repositorio oficial de Debian.

      * empaquetador de Debian (DM) («Debian Maintainer»): la persona
        que tiene permiso limitado para transferir paquetes al
        repositorio oficial de Debian.

    No puedes convertirte en desarrollador oficial de Debian (DD) de
    la noche a la mañana porque hace falta algo más que habilidades
    técnicas. No te sientas desilusionado por esto. Aún puedes subir
    tu paquete, si es útil a otras personas, como empaquetador a
    través de un patrocinador o un empaquetador de Debian.

    Ten en cuenta que no es necesario construir un paquete nuevo para
    poder convertirte en desarrollador oficial de Debian. Una opción
    para ser desarrollador oficial es contribuir al mantenimiento de
    los paquetes ya existentes en la distribución. Hay muchos
    paquetes esperando un buen responsable (véase Sección 2.2, “Elige
    el programa” ).

    Dado que nos concentramos sólo en los aspectos técnicos del
    mantenimiento de paquetes en este documento, consulta las
    siguientes referencias para aprender cómo funciona Debian y cómo
    puedes participar:

      * Debian: 17 años de software libre, "meritocracia" y
        democracia (diapositivas de introducción en inglés)

      * ¿Cómo puedo ayudar a Debian? (documentación oficial)

      * Las Preguntas Frecuentes de Debian GNU/Linux FAQ, capítulo 13
        - 'Contribuir al proyecto Debian' (documentación
        semi-oficial)

      * Debian Wiki, HelpDebian (documentación complementaria)

      * Sitio web de nuevos miembros de Debian (documentación
        oficial)

      * PUF de mentores en Debian (documentación complementaria)

1.2. Programas necesarios para el desarrollo

    Antes de empezar, debes asegurarte que tienes instalados algunos
    paquetes adicionales necesarios para el desarrollo. Observa que
    la lista no contiene paquetes marcados como esencial o requerido
    - al dar por supuesto que ya los tienes instalados.

    The following packages come with the standard Debian
    installation, so you probably have them already (along with any
    additional packages they depend on). Still, you should check them
    with aptitude show package or with dpkg -s package.

    El paquete imprescindible para el desarrollo es build-essential.
    Al instalarlo, también se instalaran otros paquetes requeridos,
    consiguiendo una instalación básica para la construcción de
    paquetes.

    Para la construcción de algunos paquetes esto seria suficiente,
    pero hay otros paquetes que, no siendo esenciales en general para
    la construcción de nuevos paquetes, puede ser útil tener
    instalados o, incluso, necesarios para el paquete que estás
    construyendo:

      * autoconf, automake y autotools-dev - muchos programas nuevos
        usan ficheros de configuración y ficheros Makefile que se
        procesan con la ayuda de programas como éstos (véase info
        autoconf, info automake). El paquete autotools-dev permite
        mantener versiones actualizadas de los archivos autoconf y
        automake y tiene documentación para usar eficientemente ese
        tipo de archivos.

      * dh-make y debhelper - dh-make es necesario para construir el
        esqueleto de nuestro paquete ejemplo, y se usarán algunas de
        las herramientas de debhelper para construir los paquetes.
        Aunque no son imprescindibles para la construcción de
        paquetes se recomiendan encarecidamente para nuevos
        desarrolladores. Hacen el proceso mucho más fácil al
        principio, y más fácil de controlar en el futuro (véase 
        dh_make(8), debhelper(1)) ^[3].

        El nuevo debmake puede utilizarse como alternativa al sistema
        estándar dh-make. Tiene más funcionalidades y una extensa
        documentación en formato HTML con ejemplos para la
        construcció de paquetes en debmake-doc.

      * devscripts - este paquete contiene algunos guiones útiles
        para los desarrolladores, pero no son necesarios para
        construir paquetes. Vale la pena mirar los paquetes
        recomendados y sugeridos por este paquete (véase /usr/share/
        doc/devscripts/README.gz).

      * fakeroot - this utility lets you emulate being root, which is
        necessary for some parts of the build process. (See fakeroot
        (1).)

      * file - este útil programa puede determinar de qué tipo es un
        fichero (véase file(1)).

      * gfortran - el compilador GNU de Fortran 95, necesario si el
        programa está escrito en Fortran (véase gfortran(1)).

      * git - este paquete instala el popular sistema de control de
        versiones, diseñado para hacer el seguimiento de proyectos
        grandes con eficacia y rapidez; se utiliza para proyectos de
        código libre importantes como es el caso del núcleo
        («kernel») de Linux (véase git(1) y git Manual (/usr/share/
        doc/git-doc/index.html)).

      * gnupg - a tool that enables you to digitally sign packages.
        This is especially important if you want to distribute
        packages to other people, and you will certainly be doing
        that when your work gets included in the Debian distribution.
        (See gpg(1).)

      * gpc - el compilador GNU de Pascal, necesario si el programa
        está escrito en Pascal. Merece la pena mencionar aquí
        fp-compiler, un compilador libre de Pascal, que también es
        bueno en esta tarea (véase gpc(1), ppc386(1)).

      * lintian - this is the Debian package checker, which lets you
        know of any common mistakes after you build the package and
        explains the errors found. (See lintian(1), Lintian User's
        Manual.)

      * patch - esta utilidad es muy práctica para modificar el
        original de un archivo a partir de un archivo de diferencias
        (elaborado por el programa diff) produciendo un archivo
        parcheado (véase patch(1)).

      * patchutils - este paquete contiene programas para trabajar
        con los «parches» como lsdiff, interdiff y filterdiff.

      * pbuilder - this package contains programs which are used for
        creating and maintaining a chroot environment. Building a
        Debian package in this chroot environment verifies the proper
        build dependency and avoids FTBFS (Fails To Build From
        Source) bugs. (see pbuilder(8) and pdebuild(1))

      * perl - Perl es uno de los lenguajes interpretados para hacer
        guiones (o «scripts») más usados en los sistemas Un*x de hoy
        en día, comúnmente se refiere a él como la «navaja suiza de
        Unix» (véase perl(1)).

      * python - Python es otro de los lenguajes interpretados para
        hacer guiones (o «scripts») en Debian debido a la combinación
        de su poder y sintaxis clara (véase python(1)).

      * quilt - este paquete ayuda a aplicar modificaciones
        («parches») y hacer el seguimiento de los cambios realizados.
        Aplica las modificaciones ordenadamente en pila, y es posible
        aplicar, deshacer y actualizar las modificaciones fácilmente
        recorriendo la pila (véase quilt(1) y /usr/share/doc/quilt/
        quilt.pdf.gz.)

      * xutils-dev - algunos programas, normalmente aquellos hechos
        para X11, también usan programas para generar Makefile
        ejecutando un conjunto de funciones de macro (véase imake(1),
        xmkmf(1)).

    Las breves descripciones dadas anteriormente sólo sirven para
    introducirte a lo que hace cada paquete. Antes de continuar, por
    favor, lee la documentación de cada programa, al menos para su
    uso normal. Puede parecerte algo duro ahora, pero más adelante
    estarás muy contento de haberla leído.

1.3. Documentos necesarios para el desarrollo

    Por último, la documentación que se indica a continuación es de 
    gran importancia y debería leerse junto con este documento:

      * debian-policy - el manual de normas de Debian incluye la
        descripción de la estructura y contenidos del archivo,
        ciertas notas sobre el diseño del sistema operativo, el
        Filesystem Hierarchy Standard («FHS», que explica dónde
        deberían estar cada fichero y directorio), y, lo más
        importante para ti, describe los requisitos que debe
        satisfacer cada paquete para ser incluido en la distribución
        (véase la copias locales en /usr/share/doc/debian-policy/
        policy.pdf.gz y /usr/share/doc/debian-policy/fhs/
        fhs-3.0.pdf.gz).

      * developers-reference - the Debian Developer's Reference
        describes all matters not specifically about the technical
        details of packaging, like the structure of the archive, how
        to rename, orphan, or adopt packages, how to do NMUs, how to
        manage bugs, best packaging practices, when and where to
        upload, etc. (See the local copy of /usr/share/doc/
        developers-reference/developers-reference.pdf.)

    Por último, la documentación que se indica a continuación es de 
    gran importancia y debería leerse junto con este documento:

      * Autotools Tutorial provides a very good tutorial for the GNU
        Build System known as the GNU Autotools, whose most important
        components are Autoconf, Automake, Libtool, and gettext.

      * gnu-standards - este paquete contiene dos documentos del
        proyecto GNU: «GNU Coding Standards», y «Information for
        Maintainers of GNU Software». Aunque no se exige su
        cumplimiento en Debian, son útiles como orientación y sentido
        común (véase las copias locales en /usr/share/doc/
        gnu-standards/standards.pdf.gz y /usr/share/doc/gnu-standards
        /maintain.pdf.gz).

    Si este documento contradice en algún aspecto a los documentos
    mencionados anteriormente, prevalecen estos últimos. Por favor,
    envía un informe de error del paquete maint-guide utilizando la
    orden reportbug.

    The following is an alternative tutorial document that you may
    read along with this document:

      * Debian Packaging Tutorial

1.4. Dónde pedir ayuda

    Before you decide to ask your question in some public place,
    please read this fine documentation:

      * archivos en /usr/share/doc/package para cada uno de los
        paquetes

      * contenidos de man command para todos los comandos pertinentes

      * contenidos de info command para todos los comandos
        pertinentes

      * contenidos de debian-mentors@lists.debian.org archivo de la
        lista de correo

      * contenidos de debian-devel@lists.debian.org mailing list
        archive

    Considera el uso eficaz de los motores de búsqueda en la web
    incluyendo site:lists.debian.org en la cadena de búsqueda, para
    limitar el dominio.

    Construir un paquete pequeño es una buena forma de aprender los
    detalles del mantenimiento de paquetes. Inspeccionar paquetes
    bien mantenidos es la mejor forma de aprender cómo otros
    mantienen paquetes.

    Si todavía tienes preguntas acerca de la construcción de paquetes
    a las que no puedes encontrar respuesta en la documentación
    disponible y los recursos web, puedes formularlas
    interactivamente:

      * debian-mentors@lists.debian.org mailing list. (Esta lista de
        correo es para los principiantes.)

      * debian-devel@lists.debian.org mailing list. (Esta lista de
        correo es para expertos.)

      * IRC tal como #debian-mentors.
   
      * Los equipos se centran en un conjunto específico de paquetes.
        (La lista completa está en https://wiki.debian.org/Teams)

      * Listas de correo en un idioma concreto como debian-devel-
        {french,italian,portuguese,spanish}@lists.debian.org o bien
        debian-devel@debian.or.jp. (La lista completa está disponible
        en https://lists.debian.org/devel.html and https://
        lists.debian.org/users.html)

    Los desarrolladores de Debian con más experiencia te ayudaran con
    gusto, si haces las preguntas después realizar el esfuerzo
    requerido.

    Cuando recibas un aviso de fallo (sí, avisos de fallos, ¡de
    verdad!) sabrás que es el momento de indagar en el Sistema de
    seguimiento de fallos de Debian y leer su documentación para
    poder tratar los informes de forma eficiente. Te recomiendo la
    lectura de la Referencia del Desarrollador, en particular el
    capítulo de «Referencia del desarrollador sección 5.8 - Manejo de
    fallos» («Handling Bugs»).

    Even if it all worked well, it's time to start praying. Why?
    Because in just a few hours (or days) users from all around the
    world will start to use your package, and if you made some
    critical error you'll get mailbombed by numerous angry Debian
    users… Just kidding. :-)

    Relájate y prepárate para recibir informes de fallos, porque hay
    mucho más trabajo que realizar antes de que tu paquete cumpla las
    Normas de Debian (una vez más lee la documentación real para más
    detalles). ¡Buena suerte!


---------------------------------------------------------------------

    ^[1] El documento asume que estás utilizando la versión jessie.
    Si quieres utilizar este documento con una versión anterior
    (incluidas versiones anteriores de Ubuntu u otras) debes instalar
    (como mínimo) la versión «backport» de los paquetes dpkg y
    debhelper.

    ^[2] Puedes aprender las operaciones básicas del sistema Debian
    en Debian Reference. Ese documento también trata algunos aspectos
    sobre programación en UNIX.

    ^[3] Hay varios paquetes similares pero más específicos como
    dh-make-perl, dh-make-php, etc.

Capítulo 2. Primeros pasos

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Vamos a construir nuestro propio paquete (o, mejor aún, adoptar
    un paquete ya existente).

2.1. Plan de trabajo para la construcción de paquetes Debian

    Si estas construyendo un paquete Debian con las fuentes
    originales, el plan de trabajo típico implica varias etapas (en
    las cuales se generan archivos con nombres específicos) y que se
    explican a continuación:

      * Conseguimos las fuentes originales del programa, normalmente
        en un archivo comprimido en formato «tar».

          + nombre_del_paquete-versión.tar.gz
      * Añadir las modificaciones específicas de Debian al programa
        original en el directorio debian, y construir un paquete de
        fuentes no nativo (es decir, el conjunto de archivos de
        entrada utilizados para la construcción de paquetes Debian)
        en formato 3.0 (quilt)).
   
          + nombre_del_paquete_versión.orig.tar.gz
          + nombre_del_paquete_versión-revisión.debian.tar.gz^[4]
          + nombre_del_paquete_versión-revisión.dsc
      * Construimos los paquetes binarios Debian, que son archivos
        instalables ordinarios en formato .deb (o en formato .udeb,
        utilizado por el instalador de Debian), desde el paquete
        fuente de Debian.

          + nombre_del_paquete_versión-revisión_arquitectura.deb

    Fíjate que el carácter que separa nombre_del_paquete y versión se
    ha cambiado de - (guión) a _ (guión bajo).

    En los nombres de archivo que siguen, nombre_del_paquete se
    substituye por el nombre del paquete, versión por la versión del
    código fuente, revisión por la revisión Debian, arquitectura por
    la arquitectura del paquete ^[5].

    Cada paso de este esquema se explica con ejemplos detallados en
    secciones posteriores.

2.2. Elige el programa

    Probablemente hayas escogido ya el paquete que deseas construir.
    Lo primero que debes hacer es comprobar si el paquete está ya en
    el archivo de la distribución utilizando:

      * la orden aptitude

      * la página web Debian packages

      * the Debian Package Tracker web page

    Si el paquete ya existe, ¡instálalo! :-) Si te encuentras con que
    el paquete es un paquete huérfano (cuando su desarrollador es el
    Debian QA Group, es decir, el grupo de calidad de Debian), puedes
    adoptarlo (convertirte en el responsable de empaquetarlo y
    mantenerlo) si está disponible. También puedes adoptar un paquete
    para el cual se ha emitido una «solicitud de adopción» (Request
    for Adoption o RFA) por su desarrollador o por un DD ^[6].

    Hay varios recursos para conocer el estado de los paquetes:

      * La orden wnpp-alert del paquete devscripts

      * Paquetes pendientes y futuros nuevos paquetes

      * Registro de informes de fallos de Debian: errores en el
        paquete wnpp en la versión unstable

      * Paquetes Debian que necesitan cariño

      * Búsqueda de errores wnpp basada en palabras clave

    A modo de nota al margen, es importante tener presente que Debian
    incorpora paquetes de un gran número de programas de todo tipo, y
    que la cantidad de paquetes disponibles en el repositorio de
    Debian es mucho mayor al de colaboradores con permiso para
    incorporar paquetes al repositorio. En consecuencia, la
    colaboración en el mantenimiento de paquetes que ya están en el
    repositorio se valora muy positivamente (y es más fácil conseguir
    patrocinador) por el resto de desarrolladores ^[7]. Puedes hacer
    esto de distintas formas:

      * hacerte cargo de paquetes huérfanos pero que son utilizados
        frecuentemente por otros usuarios

      * incorporándote a los equipos de desarrolladores.

      * seleccionando errores de los paquetes más populares

      * preparando paquetes QA o NMU

    If you are able to adopt the package, get the sources (with
    something like apt-get source packagename) and examine them. This
    document unfortunately doesn't include comprehensive information
    about adopting packages. Thankfully you shouldn't have a hard
    time figuring out how the package works since someone has already
    done the initial setup for you. Keep reading, though; a lot of
    the advice below will still be applicable to your case.

    Si el paquete es nuevo y decides que te gustaría verlo en Debian
    debes seguir los pasos indicados a continuación:

      * En primer lugar deberías saber cómo funciona, y haberlo
        utilizado durante algún tiempo (para confirmar su utilidad).

      * You must check that no one else is already working on the
        package on the Work-Needing and Prospective Packages site. If
        no one else is working on it, file an ITP (Intent To Package)
        bug report to the wnpp pseudo-package using reportbug. If
        someone's already on it, contact them if you feel you need
        to. If not — find another interesting program that nobody is
        maintaining.

      * El programa debe tener una licencia.

          + Si el paquete debe pertenecer a la sección main el
            programa debe cumplir con las Directrices de Debian para
            el software libre (DFSG) y no debe precisar la
            instalación de otro paquete que no pertenezca a la
            sección main para su compilación o ejecución como
            requiere la directiva de Debian («Debian Policy»). Es la
            situación deseada.

          + Para paquetes de la sección contrib la licencia debe
            cumplir todos los requisitos de la DFSG pero puede
            precisar la instalación de otro paquete que no sea de la
            sección main para su compilación o ejecución.

          + Para paquetes de la sección non-free, no es necesario que
            la licencia cumpla todos los requisitos de la DFSG pero 
            debe permitir la distribución del programa.

          + Si no estás seguro sobre en qué lugar debería ir, envía
            el texto de la licencia y pide consejo con un correo (en
            inglés) dirigido a debian-legal@lists.debian.org.

      * The program should not introduce security and maintenance
        concerns into the Debian system.

          + The program should be well documented and its code needs
            to be understandable (i.e., not obfuscated).

          + Deberías contactar con el autor o autores del programa
            para comprobar su conformidad con el empaquetado. Es
            importante que el autor o autores sigan manteniendo el
            programa para que puedas en el futuro consultarle/s en
            caso de que haya problemas específicos. No deberías
            intentar empaquetar programas que no estén mantenidos.

          + El programa no debería ejecutarse con «setuid root», o
            aún mejor: no debería ser «setuid» ni «setgid».

          + El programa no debería ser un demonio, o algo que vaya en
            los directorios */sbin, o abrir un puerto como usuario
            administrador.

    Of course, the last one is just a safety measure, and is intended
    to save you from enraging users if you do something wrong in some
    setuid daemon… When you gain more experience in packaging, you'll
    be able to package such software.

    Como nuevo desarrollador, es aconsejable que adquieras
    experiencia con la construcción de paquetes sencillos y se
    desaconseja construir paquetes complicados.

      * Paquetes sencillos

          + archivo binario único, arquitectura = todas (colección de
            datos como gráficos de fondo de pantalla)

          + archivo binario único, arquitectura = todas (ejecutables
            escritos en lenguajes interpretados como POSIX)

      * Paquetes de complejidad intermedia

          + paquete binario simple, arquitectura = todas (ejecutables
            ELF escritos en lenguajes compilados tales como C y C +
            +)

          + paquete binario múltiple, arquitectura = todas y
            cualquiera (paquetes de ejecutables ELF y documentación)

          + paquetes en los que el formato del archivo fuente no es
            tar.gz ni tar.bz2

          + paquetes cuyas fuentes contienen partes que no se pueden
            distribuir.

      * Paquetes muy complejos

          + paquete de módulos de lenguaje interpretado utilizado por
            otros paquetes

          + paquetes de bibliotecas ELF genéricas utilizadas por
            otros paquetes

          + múltiples paquetes binarios incluyendo un paquete(s) de
            bibliotecas ELF

          + paquetes de fuentes con múltiples originales

          + paquetes de módulos del núcleo

          + paquetes de parches del núcleo,

          + cualquier paquete de guiones de desarrollador no
            triviales

    Construir paquetes de alta complejidad no es demasiado difícil,
    pero requiere más conocimientos. Debes buscar las orientaciones
    específicas para cada caso según su complejidad. Por ejemplo,
    algunos lenguajes interpretados tienen sus normas específicas.

      * Perl policy

      * Normas para Python

      * Normas para Java

    There is another old Latin saying: fabricando fit faber (practice
    makes perfect). It is highly recommended to practice and
    experiment with all the steps of Debian packaging with simple
    packages while reading this tutorial. A trivial upstream tarball,
    hello-sh-1.0.tar.gz, created as follows may offer a good starting
    point:^[8]

    $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
    $ cat > hello <<EOF
    #!/bin/sh
    # (C) 2011 Foo Bar, GPL2+
    echo "Hello!"
    EOF
    $ chmod 755 hello
    $ cd ..
    $ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

2.3. Obtén el programa y pruébalo

    Lo primero que debes hacer es encontrar y descargar el código
    fuente original. A partir de este punto se da por supuesto que ya
    tienes el código fuente que obtuviste de la página del autor. Las
    fuentes de los programas libres de Unix (y GNU/Linux)
    generalmente vienen en formato tar+gzip, con extensión .tar.gz o
    en formato tar+bzip2 con extensión .tar.bz2, y generalmente
    contienen un subdirectorio llamado programa-versión con todas las
    fuentes en él.

    If the latest version of the source is available through a
    Version Control System (VCS) such as Git, Subversion, or CVS, you
    need to get it with git clone, svn co, or cvs co and repack it
    into tar+gzip format yourself by using the --exclude-vcs option.

    Si tu programa viene en otro tipo de archivo (por ejemplo, el
    fichero termina en .Z o .zip^[9]), descomprímelo con las
    herramientas adecuadas y reconstrúyelo de nuevo.

    Si el código fuente del programa viene con algunos contenidos que
    no cumplan con las DFSG, debes descomprimirlo para eliminar
    dichos contenidos y volver a comprimirlo modificando el código de
    versión original añadiendo dfsg.

    Como ejemplo, usaré el programa conocido como gentoo, un gestor
    de ficheros de X11 en GTK+ ^[10].

    Crea un subdirectorio en tu directorio personal llamado debian o
    deb o lo que creas apropiado (por ejemplo ~/gentoo/ estaría bien
    en este caso). Mueve a él el archivo que has descargado, y
    descomprímelo de la siguiente forma: tar xzf
    gentoo-0.9.12.tar.gz. Asegúrate de que no hay errores, incluso
    errores irrelevantes, porque es muy probable que haya problemas
    al desempaquetarlo en sistemas de otras personas, cuyas
    herramientas de desempaquetado puede que no ignoren estas
    anomalías. En el terminal de órdenes, deberías ver lo siguiente.

    $ mkdir ~/gentoo ; cd ~/gentoo
    $ wget http://www.example.org/gentoo-0.9.12.tar.gz
    $ tar xvzf gentoo-0.9.12.tar.gz
    $ ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz

    Ahora tienes otro subdirectorio, con el nombre gentoo-0.9.12.
    Accede a ese directorio y lee atentamente la documentación.
    Habitualmente encontrarás archivos con el nombre README*,
    INSTALL*, *.lsm o *.html. Deberías encontrar instrucciones sobre
    cómo compilar e instalar el programa (probablemente se asumirá
    que la instalación será en el directorio /usr/local/bin, aunque
    tú no lo harás eso, como se explica más adelante en Sección 3.3,
    “Instalación de los archivos en su destino” ).

    Deberías empezar a construir tu paquete en un directorio de
    fuentes completamente limpio, o simplemente con las fuentes
    recién desempaquetadas.

2.4. Métodos de compilación simple

    Los programas sencillos incluyen un fichero Makefile y pueden
    (generalmente) compilarse con «make»^[11]. Algunos de ellos
    soportan make check, esta orden ejecuta las comprobaciones
    automáticas que estén definidas. Generalmente se instalarán en
    sus directorios de destino ejecutando make install.

    Ahora intenta compilar y ejecutar el programa, para asegurarte
    que funciona bien y que no genera errores en el sistema mientras
    está instalándose o ejecutándose.

    También, generalmente, puedes ejecutar make clean (o mejor make
    distclean) para limpiar el directorio donde se compila el
    programa. A veces hay incluso un make uninstall que se puede
    utilizar para borrar todos los archivos instalados.

2.5. Métodos de compilación portables populares

    Buena parte de los programas libres están escritos en lenguaje C
    y C++. Muchos utilizan las «Autotools» y «CMake» para compilar en
    diferentes plataformas. Estas herramientas se utilizan para
    generar un archivo Makefile y otros archivos necesarios para la
    compilación. Así, muchos programas se compilan ejecutando «make;
    make install».

    Las Autotools son el sistema de compilación GNU e incluyen
    Autoconf, Automake, Libtool y gettext. Confirmarás que el
    programa utiliza las autoools por la presencia de los archivos
    configure.ac, Makefile.am, y Makefile.in ^[12].

    El primer paso en el uso de «Autotools» es la ejecución por parte
    del autor de la orden autoreconf -i -f la cual genera, a partir
    de los archivos fuente (a la izquierda del gráfico) los archivos
    que utilizará la orden «configure» (a la derecha del gráfico).

    configure.ac-----+-> autoreconf -+-> configure
    Makefile.am -----+        |      +-> Makefile.in
    src/Makefile.am -+        |      +-> src/Makefile.in
                              |      +-> config.h.in
                          automake
                          aclocal
                          aclocal.m4
                          autoheader

    La edición de los archivos configure.ac y Makefile.am requiere
    conocer el funcionamiento de autoconf y automake. Véase «info
    autoconf» y «info automake» (ejecutando las órdenes en el
    terminal).

    El segundo paso en el uso de «Autotools« es la ejecución de «./
    configure && make» en el directorio del código fuente para
    compilar el programa generando un archivo binario.

    Makefile.in -----+                +-> Makefile -----+-> make -> binary
    src/Makefile.in -+-> ./configure -+-> src/Makefile -+
    config.h.in -----+                +-> config.h -----+
                     |
      config.status -+
      config.guess --+

    Puedes hacer cambios en el archivo Makefile, por ejemplo
    cambiando el directorio de instalación predeterminado usando las
    opciones de la orden ejecutando: ./configure --prefix=/usr.

    Aunque no es necesario, la actualización del archivo configure y
    de otros archivos con la orden autoreconf -i -f es la mejor
    manera para mejorar la compatibilidad del código fuente ^[13].

    CMake es un sistema de compilación alternativo. La presencia del
    archivo CMakeLists.txt te indicará que se utiliza esta opción
    para compilar el programa.

2.6. Nombre del paquete y versión

    Si el código original se presenta como gentoo-0.9.12.tar.gz,
    puedes poner como nombre del paquete gentoo y como versión
    original 0.9.12. Estas referencias se utilizan en el archivo
    debian/changelog descrito más adelante en Sección 4.3, “El
    archivo changelog”.

    Although this simple approach works most of the time, you may
    need to adjust package name and upstream version by renaming the
    upstream source to follow Debian Policy and existing convention.

    You must choose the package name to consist only of lower case
    letters (a-z), digits (0-9), plus (+) and minus (-) signs, and
    periods (.). It must be at least two characters long, must start
    with an alphanumeric character, and must not be the same as
    existing packages. It is a good idea to keep its length within 30
    characters. ^[14]

    Si el código fuente original utiliza palabras genéricas tales
    como prueba-privada por nombre, es buena idea cambiarlo para no
    «contaminar» el espacio de nombres y para identificar su
    contenido en forma explícita ^[15].

    You should choose the upstream version to consist only of
    alphanumerics (0-9A-Za-z), plus signs (+), tildes (~), and
    periods (.). It must start with a digit (0-9). ^[16] It is good
    idea to keep its length within 8 characters if possible. ^[17]

    If upstream does not use a normal versioning scheme such as
    2.30.32 but uses some kind of date such as 11Apr29, a random
    codename string, or a VCS hash value as part of the version, make
    sure to remove them from the upstream version. Such information
    can be recorded in the debian/changelog file. If you need to
    invent a version string, use the YYYYMMDD format such as 20110429
    as upstream version. This ensures that dpkg interprets later
    versions correctly as upgrades. If you need to ensure smooth
    transition to the normal version scheme such as 0.1 in the
    future, use the 0~YYMMDD format such as 0~110429 as the upstream
    version.

    El código de la versión ^[18] será comparado por dpkg(1) como
    sigue:

    $ dpkg --compare-versions versión_1 op versión_2

    La regla de comparación de versiones se pueden resumir de la
    siguiente manera.

      * Las cadenas se comparan desde el inicio hasta el final.

      * Los caracteres (letras y símbolos) son anteriores a los
        números.

      * Los números se comparan como enteros.

      * Los caracteres (letras y símbolos) se comparan en el orden
        del código ASCII.

      * Hay algunas reglas especiales para los puntos (. ), símbolo
        de suma (+) y tildes (~) como se explica a continuación:

        0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 <
        1.0+nmu1 < 1.1 < 2.0

    Uno de los casos difíciles sucede cuando la versions del código
    fuente gentoo-0.9.12-ReleaseCandidate-99.tar.gz se utiliza como
    el pre-lanzamiento de gentoo-0.9.12.tar.gz. Debes asegurarte que
    la actualización funciona correctamente cambiando el nombre a las
    fuentes originales por gentoo-0.9.12~rc99.tar.gz.

2.7. Configurar dh_make

    Primero debes configurar las variables de entorno «shell»
    $DEBEMAIL y $DEBFULLNAME que son utilizadas por varias
    herramientas de mantenimiento de Debian para obtener tu nombre y
    correo electrónico como se indica a continuación ^[19].

    $ cat >>~/.bashrc <<EOF
    DEBEMAIL="tu.direccion.de.correo@ejemplo.org"
    DEBFULLNAME="Nombre Apellido"
    export DEBEMAIL DEBFULLNAME
    EOF
    $ . ~/.bashrc

2.8. Paquete no nativo Debian inicial

    Los paquetes Debian normales son paquetes no nativos construidos
    a partir de los programas originales de los autores. Si deseas
    construir un paquete Debian no nativo a partir del código fuente
    original gentoo-0.9.12.tar.gz, puedes construir un primer paquete
    de Debian no nativo ejecutando la orden dh_make como sigue:

    $ cd ~/gentoo
    $ wget http://example.org/gentoo-0.9.12.tar.gz
    $ tar -xvzf gentoo-0.9.12.tar.gz
    $ cd gentoo-0.9.12
    $ dh_make -f ../gentoo-0.9.12.tar.gz

    Deberás cambiar el nombre del archivo por el correspondiente a
    tus fuentes ^[20]. Véase dh_make(8) para una descripción más
    detallada.

    You should see some output asking you what sort of package you
    want to create. Gentoo is a single binary package — it creates
    only one binary package, i.e., one .deb file — so we will select
    the first option (with the s key), check the information on the
    screen, and confirm by pressing ENTER. ^[21]

    Tras ejecutar dh_make, se genera una copia del código original
    con el nombre gentoo_0.9.12.orig.tar.gz en el directorio raíz
    para facilitar la construcción del paquete de fuentes no nativo
    de Debian con el archivo debian.tar.gz:

    $ cd ~/gentoo ; ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz
    gentoo_0.9.12.orig.tar.gz

    Observa que hay dos cambios clave en el nombre del fichero
    gentoo_0.9.12.orig.tar.gz:

      * El nombre del paquete y la versión están separados por «_».
   
      * Hay un .orig antes de .tar.gz.

    Observa que la ejecución de la orden ha generado varios archivos
    de plantilla en el directorio debian. Se tratará sobre ellos en
    Capítulo 4, Archivos necesarios en el directorio debian y
    Capítulo 5, Otros ficheros en el directorio debian.. El proceso
    de empaquetado no está totalmente automatizado. Se tratará la
    modificación de los archivos Debian en Capítulo 3, Modificar las
    fuentes. A continuación se compilará el paquete Debian en el
    apartado Capítulo 6, Construcción del paquete, la revisión del
    resultado en Capítulo 7, Comprobación del paquete en busca de
    fallos y el envío del paquete en Capítulo 9, Enviar el paquete.
    Se explicará cada una de estas etapas a continuación.

    Si accidentalmente has eliminado alguna de las plantillas
    mientras trabajabas en ellas, puedes regenerarlas ejecutando 
    dh_make con la opción --addmissing desde el directorio con las
    fuentes del paquete Debian.

    Actualizar un paquete existente puede complicarse debido a que
    puede estar construido con técnicas más antiguas. Para aprender
    lo básico, es mejor limitarse a la construcción de un paquete
    nuevo; se amplia la explicación en Capítulo 8, Actualizar el
    paquete.

    Please note that the source file does not need to contain any
    build system discussed in Sección 2.4, “Métodos de compilación
    simple” and Sección 2.5, “Métodos de compilación portables
    populares”. It could be just a collection of graphical data, etc.
    Installation of files may be carried out using only debhelper
    configuration files such as debian/install (see Sección 5.11,
    “Archivo install”).


---------------------------------------------------------------------

    ^[4] Para paquetes no nativos Debian construidos en el formato
    anterior 1.0, se utiliza nombre_del_paquete_versión-revisión
    .diff.gz

    ^[5] Consulta 5.6.1 "Source", 5.6.7 "Package", and 5.6.12
    "Version". La arquitectura del paquete sigue el Debian Policy
    Manual, 5.6.8 "Architecture" y se asigna automáticamente en el
    proceso de compilación del paquete.

    ^[6] See Debian Developer's Reference 5.9.5 "Adopting a package".

    ^[7] Dicho esto, por supuesto, hay nuevos programas que vale la
    pena empaquetar para Debian.

    ^[8] No debes preocuparte por perder el Makefile. Puedes instalar
    la orden hello simplemente utilizando debhelper como en
    Sección 5.11, “Archivo install”, o modificando las fuentes
    originales agregando un nuevo Makefile con el objetivo install
    como en Capítulo 3, Modificar las fuentes.

    ^[9] Puedes identificar el formato de archivo utilizando la
    herramienta file cuando no es suficiente con la extensión de
    fichero.

    ^[10] Ten en cuenta que el programa ya ha sido empaquetado
    previamente. La versión actual utiliza las «Autotools» en su
    construcción y ha cambiado sustancialmente de la versión 0.9.12
    que se utiliza en los ejemplos mostrados a continuación.

    ^[11] Many modern programs come with a script named configure,
    which when executed creates a Makefile customized for your
    system.

    ^[12] Autotools is too big to deal with in this small tutorial.
    This section is meant to provide keywords and references only.
    Please make sure to read the Autotools Tutorial and the local
    copy of /usr/share/doc/autotools-dev/README.Debian.gz, if you
    need to use it.

    ^[13] Añade el paquete dh-autoreconf en el campo Build-Depends.
    Véase Sección 4.4.3, “Personalización del archivo rules”.

    ^[14] La longitud predeterminada del nombre del paquete en la
    orden aptitude es 30. En más del 90% de los paquetes, la longitud
    del nombre del paquete es inferior a 24 caracteres.

    ^[15] If you follow the Debian Developer's Reference 5.1. "New
    packages", the ITP process will usually catch this kind of issue.

    ^[16] Esta norma más estricta debería ayudar a evitar confundir
    los nombres de archivo.

    ^[17] El valor predeterminado para la longitud de la versión de
    la orden aptitude es 10. El código de la revisión Debian
    precedida por un guión consume 2. Para más del 80% de los
    paquetes, el código de la versión original es de menos de 8
    caracteres y el de la revisión Debian es de menos de 2
    caracteres. Para más del 90% de los paquetes, la versión original
    es de menos de 10 caracteres y la revisión Debian es de menos de
    3 caracteres.

    ^[18] Las cadenas de versión pueden ser la versión del código
    fuente (versión), la revisión Debian (revisión), o versión (
    versión-revisión). Consulta Sección 8.1, “Nueva revisión Debian
    del paquete” para saber cómo debe incrementarse la revisión
    Debian.

    ^[19] El texto mostrado a continuación da por supuesto que estás
    ejecutando «bash» como tu intérprete de línea de órdenes. Si
    utilizas otros intérpretes, como «Z shell», deberás utilizar sus
    correspondientes ficheros de configuración en lugar de ~/.bashrc.

    ^[20] If the upstream source provides the debian directory and
    its contents, run the dh_make command with the extra option
    --addmissing. The new source 3.0 (quilt) format is robust enough
    not to break even for these packages. You may need to update the
    contents provided by the upstream version for your Debian
    package.

    ^[21] Se ofrecen varias opciones aquí: s para un binario,i para
    un paquete independiente de la arquitectura (sólo código fuente o
    bien documentación), m para más de un binario, l para una
    biblioteca, k para un módulo del núcleo («kernel»), n para un
    parche del núcleo y b para paquetes cdbs. Este documento se
    centra en el uso del paquete debhelper con la orden dh para la
    construcción de paquetes con un binario y trata solo parcialmente
    su uso en la construcción de paquetes independientes de la
    arquitectura y con más de un binario. El paquete cdbs ofrece
    guiones alternativos a la orden dh y su uso queda fuera de este
    documento.

Capítulo 3. Modificar las fuentes

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Ten en cuenta que no hay espacio aquí para entrar en todos los
    detalles respecto a los cambios que deben hacerse en las fuentes
    originales. Sin embargo, a continuación se detallan algunos de
    los problemas más frecuentes.

3.1. Configurar quilt

    El programa quilt ofrece un método básico para realizar y guardar
    las modificaciones del código fuente para construir paquetes
    Debian. Para empaquetar, es preferible realizar algunos cambios
    en la configuración predeterminada del programa, vamos a generar
    un alias dquilt para la generación de paquetes Debian añadiendo
    la siguiente linea en el archivo ~/.bashrc. La segunda línea
    garantiza que el alias tendrá los mismos beneficios que el
    programa «quilt» con la función de auto-completar del «shell»:

    alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
    . /usr/share/bash-completion/completions/quilt
    complete -F _quilt_completion -o filenames dquilt

    A continuación, vamos a generar el archivo ~/.quiltrc-dpkg de la
    siguiente manera:

    d=. ; while [ ! -d $d/debian -a $(readlink -e $d) != / ]; do d=$d/..; done
    if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
        # if in Debian packaging tree with unset $QUILT_PATCHES
        QUILT_PATCHES="debian/patches"
        QUILT_PATCH_OPTS="--reject-format=unified"
        QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
        QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
        QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
        if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
    fi

    Véase quilt(1) y /usr/share/doc/quilt/quilt.pdf.gz para utilizar 
    quilt.

3.2. Corregir un error en el código fuente

    Let's assume you find an error in the upstream Makefile as
    follows, where install: gentoo should have been install:
    gentoo-target.

    install: gentoo
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    Vamos a arreglar este error con la orden dquilt y conservar las
    modificaciones a realizar en el archivo fix-gentoo-target.patch ^
    [22]:

    $ mkdir debian/patches
    $ dquilt new fix-gentoo-target.patch
    $ dquilt add Makefile

    Ahora cambia el archivo Makefile (con un editor) original como se
    muestra a continuación:

    install: gentoo-target
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    A continuación ejecuta dquilt para que actualice el parche
    generando el archivo debian/patches/fix-gentoo-target.patch y
    añade la descripción del parche como se describe en DEP-3: Patch
    Tagging Guidelines:

    $ dquilt refresh
    $ dquilt header -e
    ... describe el parche

3.3. Instalación de los archivos en su destino

    Por lo general, los programas se instalan a sí mismos en el
    subdirectorio /usr/local. Pero los paquetes Debian no pueden
    utilizar este directorio ya que está reservado para el uso
    privado del administrador (o de los usuarios), sino que deben
    utilizar los directorios del sistema como /usr/bin según lo
    establecido por la normativa de jerarquía del sistema de archivos
    («Filesystem Hierarchy Standard» FHS).

    Es frecuente la utilización de make(1) para la construcción
    automatizada del programa y la ejecución de la orden make install
    instala directamente el programa en la ubicación deseada
    ejecutando la sección install del archivo Makefile. En la
    construcción de los paquetes binarios de Debian, el sistema de
    construcción instala los programas en una reconstrucción de la
    estructura de directorios del programa en un directorio temporal
    en lugar de hacerlo en su destino real.

    Estas dos diferencias entre la instalación del programa y el
    proceso de construcción del paquete es manejado en Debian de
    forma transparente por debhelper con las órdenes 
    dh_auto_configure y dh_auto_install siempre que se cumplan los
    requisitos indicados a continuación:

      * El archivo Makefile debe seguir las convenciones GNU de forma
        que admita la variable $(DESTDIR) ^[23].
   
      * El código fuente sigue el estándar de la jerarquía del
        sistema de ficheros. («Filesystem Hierarchy Standard» o FHS).

    Los programas que usan autoconf de GNU cumplen automáticamente
    con las convenciones GNU y su empaquetamiento es casi automático.
    Con estos requisitos y la heurística que aplica el paquete
    debhelper, se estima que funciona sobre el 90% de paquetes sin
    tener que realizar ningún cambio intrusivo en su sistema de
    construcción. El empaquetado no es tan complicado como puede
    parecer.

    Si debes hacer cambios en el archivo Makefile, debes asegurarte
    que admite la variable $(DESTDIR). La variable $(DESTDIR) no está
    definida en el archivo y se añadirá en todas las rutas de
    directorios usadas en la instalación del programa. El guión de
    empaquetamiento establece el valor de la variable $(DESTDIR) al
    valor del directorio temporal de instalación del programa en el
    proceso de construcción del paquete.

    El directorio temporal usado por la orden dh_auto_install es
    debian/nombre_de_paquete para paquetes con un binario ^[24]. El
    contenido completo del directorio temporal será instalado en el
    sistema del usuario cuando se instale el paquete, con la
    diferencia que con dpkg la instalación se realizará a partir del
    directorio raíz del sistema.

    Aunque el programa se instale en el directorio debian/
    nombre_del_paquete será necesario que se comporte correctamente
    cuando se instale en el directorio raíz, esto es, cuando se
    instale usando el archivo .deb. Deberías evitar que el sistema de
    compilación incluya cadenas del tipo /home/mi/deb/
    nombre_del_paquete-versión/usr/share/nombre_del_paquete en los
    archivos del paquete.

    Esta es la parte importante del archivo Makefile de gentoo ^[25]:

    # ¿Dónde se colocaran los ejecutables con 'make install'?
    BIN     = /usr/local/bin
    # ¿Dónde se colocaran los iconos con 'make install'?
    ICONS   = /usr/local/share/gentoo

    We see that the files are set to install under /usr/local. As
    explained above, that directory hierarchy is reserved for local
    use on Debian, so change those paths as follows:

    # ¿Dónde se colocaran los ejecutables con 'make install'?
    BIN     = $(DESTDIR)/usr/bin
    # ¿Dónde se colocaran los iconos con 'make install'?
    ICONS   = $(DESTDIR)/usr/share/gentoo

    La ubicación correcta de los binarios, iconos, documentación,
    etc, está especificada en el «Estándar de la jerarquía del
    sistema de ficheros». Te recomiendo que leas las secciones que
    podrían aplicarse a tu paquete.

    Así pues, deberíamos instalar el binario en /usr/bin en lugar de
    /usr/local/bin y la página de manual en /usr/share/man/man1 en
    lugar de /usr/local/man/man1. No hemos mencionado ninguna página
    de manual en el Makefile de gentoo, pero la normativa de Debian
    requiere que cada programa debe tener una, así que haremos una
    más tarde y la instalaremos en /usr/share/man/man1.

    Algunos programas no usan variables en el makefile para definir
    rutas como éstas. Esto significa que tendrás que editar algunos
    de los ficheros de código C para arreglarlos y que usen las rutas
    correctas. Pero, ¿dónde buscar?, y exactamente, ¿el qué? Puedes
    probar a encontrarlos usando:

    $ grep -nr --include='*.[c|h]' -e 'usr/local/lib' .

    grep buscará recursivamente en los subdirectorios y te indicará
    el nombre del fichero y la línea cuando encuentre una
    concordancia con la cadena.

    Ahora edita esos ficheros y cambia en esas líneas usr/local/lib
    por usr/lib. Esto se puede hacer de forma automática como sigue:

    $ sed -i -e 's#usr/local/lib#usr/lib#g' \
            $(find . -type f -name '*.[c|h]')

    Si deseas confirmar cada sustitución, puedes hacerlo de forma
    interactiva de la siguiente manera:

    $ vim '+argdo %s#usr/local/lib#usr/lib#gce|update' +q \
            $(find . -type f -name '*.[c|h]')

    Después de esto deberías encontrar (en el archivo Makefile) el
    objetivo «install» (busca una línea que comience por install:) y
    renombra todas las referencias a directorios distintos de los
    definidos al comienzo del Makefile.

    En el original, el objetivo «install» de gentoo declaraba:

    install: gentoo-target
            install ./gentoo $(BIN)
            install icons/* $(ICONS)
            install gentoorc-example $(HOME)/.gentoorc

    Ahora corregiremos el error, conservando las modificaciones en el
    archivo debian/patches/install.patch con la orden dquilt.

    $ dquilt new install.patch
    $ dquilt add Makefile

    Y ahora escribe los cambios con el editor:

    install: gentoo-target
            install -d $(BIN) $(ICONS) $(DESTDIR)/etc
            install ./gentoo $(BIN)
            install -m644 icons/* $(ICONS)
            install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc

    Seguramente has notado que ahora hay una orden install -d antes
    de las demás órdenes de la regla. El Makefile original no la
    tenía porque normalmente /usr/local/bin y otros directorios ya
    existen en el sistema donde se ejecuta make install. Sin embargo,
    dado que lo instalaremos en un directorio vacío (o incluso
    inexistente), tendremos que generar cada uno de estos
    directorios.

    También podemos añadir otras cosas al final de la regla, como la
    instalación de documentación adicional que los desarrolladores
    originales a veces omiten:

           install -d $(DESTDIR)/usr/share/doc/gentoo/html
           cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html

    Después de comprobar que sea todo correcto, ejecuta dquilt para
    actualizar la modificación en el archivo debian/patches/
    install.patch y añade la descripción en la cabecera del archivo:

    $ dquilt refresh
    $ dquilt header -e
    ... describe el parche

    Ahora ya tienes un par de parches en el paquete.

     1. Corrección de un error en el código fuente: debian/patches/
        fix-gentoo-target.patch
   
     2. Una modificación específica del empaquetado Debian: debian/
        patches/install.patch

    Whenever you make changes that are not specific to the Debian
    package such as debian/patches/fix-gentoo-target.patch, be sure
    to send them to the upstream maintainer so they can be included
    in the next version of the program and be useful to everyone
    else. Also remember to avoid making your fixes specific to Debian
    or Linux — or even Unix! Make them portable. This will make your
    fixes much easier to apply.

    Ten en cuenta que no tienes que enviar ninguno de los ficheros
    debian/* al desarrollador original.

3.4. Diferencias en las bibliotecas

    There is one other common problem: libraries are often different
    from platform to platform. For example, a Makefile can contain a
    reference to a library that doesn't exist on the Debian system.
    In that case, we need to change it to a library that does exist
    in Debian, and serves the same purpose.

    Vamos a suponer que en el archivo Makefile (o Makefile.in) de tu
    programa se declara algo como lo siguiente.

    LIBS = -lfoo -lbar

    Si el programa no se compila debido a que ya no existe la
    biblioteca nombre_biblioteca y su equivalente es proporcionada
    por la biblioteca nombre_biblioteca2 en el sistema Debian, puedes
    solucionar este problema de compilación, cambiando (en el archivo
    debian/patches/parche2.patch) nombre_biblioteca por
    nombre_biblioteca2 ^[26]:

    $ dquilt new foo2.patch
    $ dquilt add Makefile
    $ sed -i -e 's/-lfoo/-lfoo2/g' Makefile
    $ dquilt refresh
    $ dquilt header -e
    ... describe el cambio


---------------------------------------------------------------------

    ^[22] El directorio debian/patches debería haberse creado en la
    anterior ejecución de dh_make. Sólo debes generarlo si no existe
    o bien si estás actualizando un paquete.

    ^[23] Consulta GNU Coding Standards: 7.2.4 DESTDIR: Support for
    Staged Installs.

    ^[24] Para paquetes con más de un archivo binario, la orden 
    dh_auto_install utiliza como directorio temporal debian/tmp
    mientras que la orden dh_install con la ayuda de los archivos
    debian/paquete-1.install y debian/paquete-2.install distribuirá
    el contenido del directorio debian/tmp en los directorios
    temporales debian/paquete-1 y debian/paquete-2 para construir los
    paquetes binarios package-1_*.deb y package-2_*.deb.

    ^[25] Se trata solo de un ejemplo del contenido del archivo
    Makefile. Si el archivo Makefile se construye con la orden ./
    configure, la forma correcta de solucionar este tipo de errores
    en los archivos Makefile es ejecutando la orden ./configure desde
    la orden dh_auto_configure con las opciones predeterminadas
    añadiendo --prefix=/usr.

    ^[26] Si hay cambios en el API de la biblioteca nombre_biblioteca
    a nombre_biblioteca2, se deberá cambiar el código fuente para que
    se corresponda con la nueva API.

Capítulo 4. Archivos necesarios en el directorio debian

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Ahora hay un nuevo subdirectorio bajo el directorio principal del
    programa («gentoo-0.9.12»), que se llama debian. Hay algunos
    ficheros en este directorio que debemos editar para adaptar el
    comportamiento del paquete. La parte más importante es modificar
    los ficheros control, changelog, copyright y rules que son
    necesarios en todos los paquetes. ^[27]

4.1. El archivo control

    Este fichero contiene varios valores que dpkg, dselect, apt-get, 
    apt-cache, aptitude y otras herramientas de gestión de paquetes
    usarán para gestionar el paquete. Su contenido está concretado en
    Debian Policy Manual, 5 'Control files and their fields'.

    Aquí está el fichero de control que dh_make construye para
    nosotros:

     1 Source: gentoo
     2 Section: unknown
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10)
     6 Standards-Version: 4.0.0
     7 Homepage: <insert the upstream URL, if relevant>
     8
     9 Package: gentoo
    10 Architecture: any
    11 Depends: ${shlibs:Depends}, ${misc:Depends}
    12 Description: <insert up to 60 chars description>
    13  <insert long description, indented with spaces>

    (He añadido los números de línea)

    Lines 1–7 are the control information for the source package.
    Lines 9–13 are the control information for the binary package.

    La línea 1 es el nombre del paquete fuente.

    La línea 2 es la sección de la distribución dentro de la que
    estará este paquete.

    Como puede que hayas notado, Debian está dividida en secciones:
    main (principal, los programas libres o de código abierto),
    non-free (no libre, los programas que no son libres, que son de
    propietario) y contrib (programas libres que dependen de
    programas no libre o de propietario). Bajo ellas hay
    subdivisiones lógicas que describen en una palabra qué paquetes
    hay dentro. Así que tenemos admin para programas que sólo usa un
    administrador, base para las herramientas básicas, devel para las
    herramientas de programación, doc para la documentación, libs
    para las bibliotecas, mail para lectores y demonios de correo-e,
    net para aplicaciones y demonios de red, x11 para programas
    específicos de X11, y muchos más. ^[28]

    Vamos a cambiarla para que ponga «x11». El prefijo main/ ya va
    implícito, así que podemos omitirlo.

    La línea 3 describe cómo de importante es para el usuario la
    instalación de este paquete ^[29].

      * La prioridad optional se utiliza para paquetes nuevos que no
        entran en conflicto con otros de prioridad required,
        important o standard.

    «Section» y «Priority» se usan en las interfaces como aptitude
    cuando ordenan los paquetes y seleccionan los predeterminados.
    Una vez que envíes el paquete a Debian, el valor de estos dos
    campos puede no ser aceptado por los responsables del archivo, en
    cuyo caso te lo notificarán por correo electrónico.

    Como es un paquete de prioridad normal y no tiene conflictos con
    ningún otro, lo dejaremos con prioridad optional (opcional).

    La línea 4 es el nombre y correo electrónico del desarrollador.
    Asegúrate de que este campo incluye una cabecera válida To
    («A:»), para una dirección de correo electrónico, porque después
    de que envíes el paquete, el sistema de seguimiento de errores
    («Bug Tracking System») utilizará esta dirección para enviarte
    los mensajes de los errores. Evita usar comas, el signo «&» y
    paréntesis.

    Line 5 includes the list of packages required to build your
    package as the Build-Depends field. You can also have the
    Build-Depends-Indep field as an additional line here. ^[30] Some
    packages like gcc and make which are required by the
    build-essential package are implied. If you need to have other
    tools to build your package, you should add them to these fields.
    Multiple entries are separated with commas; read on for the
    explanation of binary package dependencies to find out more about
    the syntax of these lines.

      * Para todos los paquetes construidos con la orden dh en el
        archivo debian/rules, estará debhelper (>=9) en el campo
        Build-Depends para ajustarse a las normas de Debian respecto
        al objetivo clean.

      * Source packages which have binary packages with Architecture:
        any are rebuilt by the autobuilder. Since this autobuilder
        procedure installs only the packages listed in the
        Build-Depends field before running debian/rules build (see
        Sección 6.2, “Autobuilder”), the Build-Depends field needs to
        list practically all the required packages, and
        Build-Depends-Indep is rarely used.

      * En el caso de los paquetes de fuentes que incluyen paquetes
        binarios únicamente del tipo Architecture: all, el campo
        Build-Depends-Indep debe listar todos los paquetes excepto
        los listados en el campo Build-Depends para satisfacer los
        requerimientos de las normas de Debian respecto al objetivo
        clean.

    En caso de duda, utiliza el campo Build-Depends ^[31].

    Para saber qué paquetes son necesarios para compilar el tuyo
    ejecuta esta orden:

    $ dpkg-depcheck -d ./configure

    Para buscar manualmente las dependencias de compilación para el
    paquete /usr/bin/nombre_del_paquete, deberías ejecutar:

    $ objdump -p /usr/bin/nombre_del_paquete | grep NEEDED

    and for each library listed (e.g., libfoo.so.6), execute

    $ dpkg -S libfoo.so.6

    Debes utilizar la versión -dev de cada uno de los paquetes dentro
    de la entrada Build-Depends. Si usas ldd para este propósito,
    también te informará de las dependencias de bibliotecas
    indirectas, lo que puede llevar a que se introduzcan demasiadas
    dependencias de construcción.

    gentoo también depende de xlibs-dev, libgtk1.2-dev y
    libglib1.2-dev para su construcción, así que lo añadiremos junto
    a debhelper.

    La línea 6 es la versión de los estándares definidos en las
    normas de Debian que sigue este paquete, es decir, la versión del
    manual de normas que has leído mientras haces tu paquete (véase
    «Debian Policy Manual»).

    En la línea 7 está la dirección URL de la página web del programa
    (donde has obtenido las fuentes).

    La línea 9 es el nombre del paquete binario. Este suele ser el
    mismo que el del paquete fuente, aunque no es necesario que sea
    así siempre.

    La linea 10 describe las arquitecturas en las que puede
    compilarse el paquete binario. Este valor suele ser uno de los
    listados a continuación dependiendo del tipo de paquete ^[32]:

      * Architecture: any

          + El paquete binario generado depende de la arquitectura si
            consiste en un programa escrito en un lenguaje compilado.
   
      * Architecture: all

          + El paquete binario generado es independiente de la
            arquitectura si consiste en archivos de texto, imágenes o
            guiones escritos en lenguajes interpretados.

    Eliminamos la línea 10 debido a que el programa está escrito en
    C. dpkg-gencontrol(1) la rellenará con el valor apropiado cuando
    se compile este paquete en cualquier arquitectura para la cual
    pueda ser compilado.

    Si tu paquete es independiente de la arquitectura (por ejemplo,
    un documento, un guión escrito en Perl o para el intérprete de
    órdenes), cambia esto a all, y consulta más adelante Sección 4.4,
    “El archivo rules” sobre cómo usar la regla binary-indep en lugar
    de binary-arch para construir el paquete.

    La línea 11 muestra una de las más poderosas posibilidades del
    sistema de paquetes de Debian. Los paquetes se pueden relacionar
    unos con otros de diversas formas. Aparte de Depends (depende de)
    otros campos de relación son Recommends (recomienda), Suggests
    (sugiere), Pre-Depends (predepende de), Breaks (rompe a),
    Conflicts (entra en conflicto con), Provides (provee), Replaces
    (reemplaza a).

    Las herramientas de gestión de paquetes se comportan
    habitualmente de la misma forma cuando tratan con esas relaciones
    entre paquetes; si no es así, se explicará en cada caso. (véase 
    dpkg(8), dselect(8), apt(8), aptitude(1), etc.)

    He aquí una descripción simplificada de relaciones entre
    paquetes: ^[33]

      * Depends:

        No se instalará el programa a menos que los paquetes de los
        que depende estén ya instalados. Usa esto si tu programa no
        funcionará de ninguna forma (o se romperá fácilmente) a no
        ser que se haya instalado un paquete determinado.

      * Recommends:

        Esta opción es para paquetes cuya instalación no es
        estrictamente necesaria para el funcionamiento de tu programa
        pero que suelen utilizarse junto con tu programa. Cuando los
        usuarios instalen tu paquete, todas las interfaces de
        instalación aconsejaran la instalación de los paquetes
        recomendados. aptitude y apt-get instalan los paquetes
        recomendados (pero el usuario puede decidir no hacerlo). dpkg
        ignora el contenido de este campo.

      * Suggests:

        Utiliza esto para paquetes que funcionarán bien con tu
        programa pero que no son necesarios en absoluto. Es posible
        configurar aptitude para que instale los paquetes sugeridos,
        aunque no es la opción predeterminada. dpkg y apt-get
        ignorarán estas dependencias.

      * Pre-Depends:

        Esto es más fuerte que Depends. El paquete no se instalará a
        menos que los paquetes de los que pre-dependa estén
        instalados y correctamente configurados. Utiliza esto muy
        poco y sólo después de haberlo discutido en la lista de
        distribución (debian-devel@lists.debian.org). En resumidas
        cuentas: no lo utilices en absoluto :-)

      * Conflicts:

        El paquete no se instalará hasta que todos los paquetes con
        los que entra en conflicto hayan sido eliminados. Utiliza
        esto si tu programa no funcionará en absoluto (o fallará
        fácilmente) si un paquete en concreto está instalado.

      * Breaks:

        Si el paquete se instala, todos los paquetes de la lista se
        romperán. Normalmente, los paquetes incluidos en la lista
        Breaks tienen una cláusula de versión anterior. La solución
        es actualizar los paquetes de la lista a la versión más
        actual.

      * Provides:

        For some types of packages where there are multiple
        alternatives, virtual names have been defined. You can get
        the full list in the virtual-package-names-list.txt.gz file.
        Use this if your program provides a function of an existing
        virtual package.

      * Replaces:

        Usa esto si tu programa reemplaza ficheros de otro paquete o
        reemplaza totalmente otro paquete (generalmente se usa
        conjuntamente con Conflicts). Se sobrescribirán los ficheros
        de los paquetes indicados con los ficheros de tu paquete.

    Todos estos campos tienen una sintaxis uniforme: se trata de una
    lista de nombres de paquetes separados por comas. Estos nombres
    de paquetes también puede ser listas de paquetes alternativos,
    separados por los símbolos de barra vertical «|» (símbolos
    tubería).

    Los campos pueden restringir su aplicación a versiones
    determinadas de cada paquete nombrado. Esto se hace listando
    después de cada nombre de paquete individual las versiones entre
    paréntesis, e indicando antes del número de versión una relación
    de la siguiente lista. Las relaciones permitidas son: <<, <=, =,
    >= y >> para estrictamente anterior, anterior o igual,
    exactamente igual, posterior o igual o estrictamente posterior,
    respectivamente. Por ejemplo:

    Depends: foo (>= 1.2), libbar1 (= 1.3.4)
    Conflicts: baz
    Recommends: libbaz4 (>> 4.0.7)
    Suggests: quux
    Replaces: quux (<< 5), quux-foo (<= 7.6)

    La última funcionalidad que necesitas conocer es $
    {shlibs:Depends},${perl:Depends}, ${misc:Depends}, etc.

    Después de que tu paquete se compile y se instale en el
    directorio temporal, dh_shlibdeps(1) lo escaneará en busca de
    binarios y bibliotecas para determinar las dependencias de
    bibliotecas compartidas. Esta lista se utiliza para la
    sustitución de ${shlibs:Depends}.

    La orden dh_perl(1) genera las dependencias de Perl. Genera la
    lista de dependencias de perl o perlapi para cada paquete
    binario. Esta lista es utilizada para substituir a $
    {perl:Depends}.

    Algunas órdenes de debhelper determinan las dependencias de los
    paquetes listados anteriormente. Cada orden generar una lista de
    los paquetes necesarios para cada paquete binario. La lista de
    estos paquetes se usará para substituir a ${misc:Depends}.

    La orden dh_gencontrol(1) genera el archivo DEBIAN/control para
    cada paquete binario substituyendo ${shlibs:Depends}, $
    {perl:Depends}, ${misc:Depends}, etc.

    Después de decir todo esto, podemos dejar la línea de Depends
    exactamente como está ahora e insertar otra línea tras ésta con
    el texto Suggests: file, porque gentoo utiliza algunas funciones
    proporcionadas por el paquete/programa file.

    La línea 9 es la dirección URL del programa. Supongamos que es
    http://www.obsession.se/gentoo/.

    La línea 12 es una descripción corta. La mayor parte de los
    monitores (en realidad, de las terminales en modo de texto) de la
    gente son de 80 columnas de ancho, así que no debería tener más
    de 60 caracteres. Cambiaré esto a fully GUI-configurable,
    two-pane X file manager. («Gestor de ficheros GTK+ completamente
    configurable por GUI»).

    La línea 13 es donde va la descripción larga del paquete. Debería
    ser al menos de un párrafo que dé más detalles del paquete. La
    primera columna de cada línea debería estar vacía. No puede haber
    líneas en blanco, pero puedes poner un . (punto) en una columna
    para simularlo. Tampoco debe haber más de una línea en blanco
    después de la descripción completa ^[34].

    Vamos a añadir los campos Vcs-* para documentar la localización
    del sistema de control de versiones (VCS) entre las lineas 6 y 7
    ^[35]. Se supone que el paquete gentoo está alojado en el
    servicio «Debian Alioth Git» en git://git.debian.org/git/
    collab-maint/gentoo.git.

    Aquí está el archivo control actualizado:

     1 Source: gentoo
     2 Section: x11
     3 Priority: optional
     4 Maintainer: Josip Rodin <joy-mg@debian.org>
     5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
     6 Standards-Version: 4.0.0
     7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git
     8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git
     9 Homepage: http://www.obsession.se/gentoo/
    10
    11 Package: gentoo
    12 Architecture: any
    13 Depends: ${shlibs:Depends}, ${misc:Depends}
    14 Suggests: file
    15 Description: fully GUI-configurable, two-pane X file manager
    16  gentoo is a two-pane file manager for the X Window System. gentoo lets the
    17  user do (almost) all of the configuration and customizing from within the
    18  program itself. If you still prefer to hand-edit configuration files,
    19  they're fairly easy to work with since they are written in an XML format.
    20  .
    21  gentoo features a fairly complex and powerful file identification system,
    22  coupled to an object-oriented style system, which together give you a lot
    23  of control over how files of different types are displayed and acted upon.
    24  Additionally, over a hundred pixmap images are available for use in file
    25  type descriptions.
    26  .
    29  gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit
    30  for its interface.

    (He añadido los números de línea)

4.2. El archivo copyright

    Este fichero contiene la información sobre los recursos, licencia
    y derechos de autoría de las fuentes originales del paquete. El
    formato no está definido en las normas, pero sí sus contenidos en
    «Debian Policy Manual, 12.5 "Copyright information" y DEP-5:
    Machine-parseable debian/copyright proporciona directrices sobre
    su formato.

    dh_make proporciona una plantilla para el archivo copyright. Con
    la opción --copyright gpl2 se consigue la plantilla para el
    paquete gentoo con la licencia GPL-2.

    You must fill in missing information to complete this file, such
    as the place you got the package from, the actual copyright
    notice, and the license. For certain common free software
    licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,
    LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, 3-Clause BSD,
    CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just
    refer to the appropriate file in the /usr/share/common-licenses/
    directory that exists on every Debian system. Otherwise, you must
    include the complete license.

    En resumen, el archivo copyright del paquete gentoo debería ser
    similar a esto:

     1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
     2 Upstream-Name: gentoo
     3 Upstream-Contact: Emil Brink <emil@obsession.se>
     4 Source: http://sourceforge.net/projects/gentoo/files/
     5
     6 Files: *
     7 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
     8 License: GPL-2+
     9
    10 Files: icons/*
    11 Copyright: 1998 Johan Hanson <johan@tiq.com>
    12 License: GPL-2+
    13
    14 Files: debian/*
    15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
    16 License: GPL-2+
    17
    18 License: GPL-2+
    19  This program is free software; you can redistribute it and/or modify
    20  it under the terms of the GNU General Public License as published by
    21  the Free Software Foundation; either version 2 of the License, or
    22  (at your option) any later version.
    23  .
    24  This program is distributed in the hope that it will be useful,
    25  but WITHOUT ANY WARRANTY; without even the implied warranty of
    26  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    27  GNU General Public License for more details.
    28  .
    29  You should have received a copy of the GNU General Public License along
    30  with this program; if not, write to the Free Software Foundation, Inc.,
    31  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
    32  .
    33  On Debian systems, the full text of the GNU General Public
    34  License version 2 can be found in the file
    35  '/usr/share/common-licenses/GPL-2'.

    (He añadido los números de línea)

    Por favor, sigue el COMO redactado por «ftpmasters» y enviado a
    «debian-devel-announce»: http://lists.debian.org/
    debian-devel-announce/2006/03/msg00023.html.

4.3. El archivo changelog

    Este es un fichero requerido, con un formato especial descrito en
    Debian Policy Manual, 4.4 "debian/changelog". Este es el formato
    utilizado por dpkg y otros programas para obtener el número de
    versión, revisión, distribución y urgencia de tu paquete.

    Para ti es también importante, ya que es bueno tener documentados
    todos los cambios que hayas hecho. Esto ayudará a las personas
    que se descarguen tu paquete para ver si hay temas pendientes en
    el paquete que deberían conocer de forma inmediata. Se guardará
    como /usr/share/doc/gentoo/changelog.Debian.gz en el paquete
    binario.

    dh_make genera uno predeterminado, el cual es como sigue:

    1  gentoo (0.9.12-1) unstable; urgency=medium
    2
    3   * Initial release. (Closes: #nnnn)  <nnnn is the bug number of your ITP>
    4
    5  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    6

    (He añadido los números de línea)

    Line 1 is the package name, version, distribution, and urgency.
    The name must match the source package name; distribution should
    be unstable, and urgency should be set to medium unless there is
    any particular reason for other values.

    Lines 3-5 are a log entry, where you document changes made in
    this package revision (not the upstream changes — there is a
    special file for that purpose, created by the upstream authors,
    which you will later install as /usr/share/doc/gentoo/
    changelog.gz). Let's assume your ITP (Intent To Package) bug
    report number was 12345. New lines must be inserted just below
    the uppermost line that begins with * (asterisk). You can do it
    with dch(1). You can edit this manually with a text editor as
    long as you follow the formatting convention used by the dch(1).

    In order to prevent a package being accidentally uploaded before
    completing the package, it is a good idea to change the
    distribution value to an invalid distribution value of
    UNRELEASED.

    Terminarás con algo así:

    1  gentoo (0.9.12-1) UNRELEASED; urgency=low
    2
    3   * Initial Release. Closes: #12345
    4   * This is my first Debian package.
    5   * Adjusted the Makefile to fix $(DESTDIR) problems.
    6
    7  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
    8

    (He añadido los números de línea)

    Cuando estés satisfecho con los cambios realizados y estén
    documentados en el fichero changelog, entonces cambie el nombre
    de la distribución de UNRELEASED a unstable (o bien a
    experimental). ^[36]

    Puedes leer más sobre cómo actualizar el fichero changelog más
    adelante en Capítulo 8, Actualizar el paquete .

4.4. El archivo rules

    Now we need to take a look at the exact rules that 
    dpkg-buildpackage(1) will use to actually create the package.
    This file is in fact another Makefile, but different from the one
    (s) in the upstream source. Unlike other files in debian, this
    one is marked as executable.

4.4.1. Objetivos del archivo rules

    Cada archivo rules, como cualquier otro archivo Makefile, se
    compone de varias reglas, cada una de ellas define el objetivo y
    cómo se ejecuta ^[37]. Cada nueva regla empieza con la
    declaración del objetivo en la primera columna. Las líneas
    siguientes empiezan con un código de tabulación (ASCII 9) y
    especifican cómo llevar a cabo ese objetivo. Las líneas en blanco
    o que empiezan con # se tratan como comentarios y se ignoran ^
    [38].

    A rule that you want to execute is invoked by its target name as
    a command line argument. For example, debian/rules build and
    fakeroot make -f debian/rules binary execute rules for build and
    binary targets, respectively.

    A continuación se proporciona una explicación simplificada de los
    distintos objetivos.

      * clean (obligatorio): elimina todos los archivos generados,
        compilados o innecesarios del árbol de directorios de las
        fuentes.

      * build (obligatorio): para la construcción de archivos
        compilados a partir de los archivos fuente o la construcción
        de documentos formateados.

      * objetivo build-arch (obligatorio): para la compilación de las
        fuentes en programas compilados (dependientes de la
        arquitectura) en el árbol de directorios de compilación.

      * objetivo build-indep (obligatorio): para la compilación de
        las fuentes en documentos formateados (independientes de la
        arquitectura) en el árbol de directorios de compilación.

      * install (opcional): para la instalación en la estructura de
        directorios temporal bajo el directorio debian de los
        archivos para cada uno de los paquetes binarios. Si existe el
        objetivo binary*, dependerá de este.

      * binary (obligatorio): para la construcción de cada uno de los
        paquetes binarios (combinado con los objetivos binary-arch y
        binary-indep) ^[39].

      * binary-arch (obligatorio): para la construcción de paquetes
        dependientes de la arquitectura (Architecture: any) ^[40].

      * binary-indep (obligatorio): para la construcción de paquetes
        independientes de la arquitectura (Architecture: all) ^[41].

      * get-orig-source (opcional): para obtener la versión más
        reciente de las fuentes originales desde el lugar de
        almacenaje del autor.

    Probablemente ya te hayas perdido, pero todo quedará más claro
    después de ver el fichero rules que dh_make pone por omisión.

4.4.2. Archivo rules predeterminado

    La nueva versión de dh_make genera un archivo rules muy simple
    pero poderoso utilizando la orden dh:

     1 #!/usr/bin/make -f
     2 # See debhelper(7) (uncomment to enable)
     3 # output every command that modifies files on the build system.
     4 #DH_VERBOSE = 1
     5
     6 # see FEATURE AREAS in dpkg-buildflags(1)
     7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
     8
     9 # see ENVIRONMENT in dpkg-buildflags(1)
    10 # package maintainers to append CFLAGS
    11 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
    12 # package maintainers to append LDFLAGS
    13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
    14
    15
    16 %:
    17         dh $@

    (He añadido los números de línea y añadido algunos comentarios.
    En el fichero debian/rules los espacios iniciales de las líneas
    son tabulaciones)

    Probablemente estés familiarizado con líneas como la primera de
    guiones escritos en shell o Perl. Esta línea indica que el
    fichero debe ejecutarse con/usr/bin/make.

    La linea 4 debe descomentarse para asignar el valor 1 a la
    variable DH_VERBOSE. Entonces, la orden dh mostrará (en el
    terminal) las órdenes dh_* ejecutadas por dh. Puedes añadir la
    linea export DH_OPTIONS=-v aquí. Así podrás ver la salida de la
    ejecución de cada orden dh_* y solucionar los problemas que se
    produzcan. Esto te ayudará a entender como funciona el archivo
    rules y a solucionar problemas. Esta nueva orden dh es parte
    fundamental de las herramientas debhelper y no te esconde nada.

    Lines 16 and 17 are where all the work is done with an implicit
    rule using the pattern rule. The percent sign means "any
    targets", which then call a single program, dh, with the target
    name. ^[42] The dh command is a wrapper script that runs
    appropriate sequences of dh_* programs depending on its argument.
    ^[43]

      * debian/rules clean ejecuta dh clean, que a su vez ejecuta lo
        siguiente:

        dh_testdir
        dh_auto_clean
        dh_clean

      * debian/rules build runs dh build, which in turn runs the
        following:

        dh_testdir
        dh_auto_configure
        dh_auto_build
        dh_auto_test

      * fakeroot debian/rules binary runs fakeroot dh binary, which
        in turn runs the following^[44]:

        dh_testroot
        dh_prep
        dh_installdirs
        dh_auto_install
        dh_install
        dh_installdocs
        dh_installchangelogs
        dh_installexamples
        dh_installman
        dh_installcatalogs
        dh_installcron
        dh_installdebconf
        dh_installemacsen
        dh_installifupdown
        dh_installinfo
        dh_installinit
        dh_installmenu
        dh_installmime
        dh_installmodules
        dh_installlogcheck
        dh_installlogrotate
        dh_installpam
        dh_installppp
        dh_installudev
        dh_installwm
        dh_installxfonts
        dh_bugfiles
        dh_lintian
        dh_gconf
        dh_icons
        dh_perl
        dh_usrlocal
        dh_link
        dh_compress
        dh_fixperms
        dh_strip
        dh_makeshlibs
        dh_shlibdeps
        dh_installdeb
        dh_gencontrol
        dh_md5sums
        dh_builddeb

      * fakeroot debian/rules binary-arch runs fakeroot dh
        binary-arch, which in turn runs the same sequence as fakeroot
        dh binary but with the -a option appended for each command.

      * fakeroot debian/rules binary-indep runs fakeroot dh
        binary-indep, which in turn runs almost the same sequence as
        fakeroot dh binary but excluding dh_strip, dh_makeshlibs, and
        dh_shlibdeps with the -i option appended for each remaining
        command.

    La función de las órdenes dh_* puede deducirse de su nombre ^[45]
    . A continuación se resume las funciones de las órdenes más
    importantes asumiendo que se utiliza un sistema de compilación
    basado en un archivo Makefile ^[46]:

      * dh_auto_clean normalmente ejecuta lo siguiente, siempre que
        exista un fichero Makefile con el objetivo distclean^[47].

        make distclean

      * dh_auto_configure ejecuta lo siguiente si existe el archivo ./
        configure (se han abreviado los argumentos para facilitar la
        lectura).

        ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...

      * dh_auto_build ejecuta lo siguiente para ejecutar el primer
        objetivo del archivo Makefile (supuesto que este existe).
   
        make

      * dh_auto_test ejecuta lo siguiente si existe el objetivo test en
        el archivo Makefile ^[48].

        make test

      * dh_auto_install ejecuta lo siguiente si en el archivo Makefile
        existe el objetivo install (se ha truncado la linea para permitir
        su lectura).

        make install \
          DESTDIR=/ruta/a/paquete_versión-revisión/debian/paquete

    Los objetivos que deben ejecutarse con la orden fakeroot
    contienen dh_testroot. Si no utilizas la orden para simular la
    ejecución por el usuario «root», se producirá un error que
    detendrá la ejecución.

    Es importante tener presente que el archivo rules que genera 
    dh_make es sólo una sugerencia. Será suficiente para la mayoría
    de los paquetes simples, pero no dejes de adaptarlo a tus
    necesidades en paquetes más complejos.

    A pesar de que install no es un objetivo obligatorio, se admite
    su uso. fakeroot dh install se comporta como fakeroot dh binary
    pero se detiene después de dh_fixperms.

4.4.3. Personalización del archivo rules

    Puedes realizar muchos cambios para adaptar el archivo rules
    construido por la orden dh.

    La orden dh $@ permite las siguientes adaptaciones ^[49]:

      * Añadir la orden dh_python2 (la mejor opción para Python) ^
        [50].

          + Añade el paquete python en el campo Build-Depends.

          + Utiliza dh $@ --with python2 en su lugar.

          + Esto gestiona el módulo Python utilizando las
            funcionalidades de python.

      * Añadir la orden pysupport. (obsoleto)

          + Añade el paquete python-support en el campo
            Build-Depends.

          + Utiliza dh $@ --with pysupport.

          + Esto gestiona el módulo Python utilizando las
            funcionalidades de python-support.

      * Añadir la orden dh_pycentral. (obsoleto)

          + Añade el paquete python-central en el campo
            Build-Depends.

          + Utiliza dh $@ --with python-central en su lugar.

          + Esto desactiva la orden dh_pysupport.

          + Esto gestiona el módulo Python utilizando las
            funcionalidades de python-central.

      * Añadir la orden dh_installtex.

          + Añade el paquete tex-common en el campo Build-Depends.

          + Utiliza dh $@ --with tex en su lugar.

          + Esto registra el tipo de letra «Type 1», los patrones de
            separación de palabras («hyphenation patterns») o los
            formatos TeX.

      * Añadir las órdenes dh_quilt_patch y dh_quilt_unpatch.

          + Añade el paquete quilt en el campo Build-Depends.

          + Utiliza dh $@ --with quilt en su lugar.

          + Esto aplica o revierte los parches en los archivos de las
            fuentes originales, basándose en los ficheros del
            directorio debian/patches en los paquetes con el formato
            1.0.
   
          + Esta adaptación no es necesaria para los paquetes con el
            nuevo formato 3.0 (quilt).

      * Añadir la orden dh_dkms.

          + Añade el paquete dkms en el campo Build-Depends.

          + Utiliza dh $@ --with dkms en su lugar.

          + Esto controla correctamente el uso de DKMS en la
            construcción de paquetes del núcleo.

      * Añadir las ordenes dh_autotools-dev_updateconfig y 
        dh_autotools-dev_restoreconfig.

          + Añade el paquete autotools-dev en el campo Build-Depends.

          + Utiliza dh $@ --with autotools-dev en su lugar.

          + Esto actualiza y restaura config.sub y config.guess.

      * Añadir la orden dh_autoreconf y dh_autoreconf_clean.

          + Añade el paquete dh-autoreconf en el campo Build-Depends.

          + Utiliza dh $@ --with autoreconf en su lugar.

          + Así se actualiza los archivos del sistema de compilación
            GNU y los restaura después de la compilación.

      * Añadir la orden dh_girepository.

          + Añade el paquete gobject-introspection en el campo
            Build-Depends.

          + Utiliza dh $@ --with gir en su lugar.

          + Esto calcula las dependencias de paquetes de envío de
            datos de introspección de «GObject» y genera la
            substitución de la variable ${gir:Depends} por las
            dependencias del paquete.

      * Añadir la funcionalidad de autocompletar a bash.

          + Añade el paquete bash-completion en el campo
            Build-Depends.

          + Utiliza dh $@ --with bash-completion en su lugar.

          + Esto instala la función autocompletar de bash utilizando
            el archivo de configuración de debian/nombre_del_paquete
            .bash-completion.

    Muchas de las órdenes dh_* invocadas por la nueva orden dh son
    personalizables mediante sus archivos de configuración en el
    directorio debian. Véase Capítulo 5, Otros ficheros en el
    directorio debian. y los manuales (las «manpage») para cada
    orden.

    Algunas órdenes dh_* invocadas por la nueva orden dh pueden
    precisar la adición de argumentos (opciones), la ejecución de
    órdenes adicionales u omitirlas del todo. Para estos casos,
    deberás añadir el objetivo override_dh_nombre_de_la_orden con las
    reglas a ejecutar en el archivo rules sólo para la orden dh_
    nombre_de_la_orden que vas a cambiar. Se trata de decir ejecútame
    a mí en su lugar ^[51].

    Las ordenes dh_auto_* hacen más cosas que las expuestas aquí. El
    uso de ordenes equivalentes más sencillas en lugar de éstas en
    los objetivos override_dh_* (excepto el objetivo
    override_dh_auto_clean) es una mala idea ya que puede eliminar
    funciones inteligentes de debhelper.

    Si vas a guardar los datos de configuración del paquete gentoo en
    el directorio /etc/gentoo en lugar del directorio habitual /etc,
    debes anular la ejecución del argumento predeterminado
    --sysconfig=/etc de la orden dh_auto_configure por ./configure
    con lo siguiente:

    override_dh_auto_configure:
            dh_auto_configure -- --sysconfig=/etc/gentoo

    The arguments given after -- are appended to the default
    arguments of the auto-executed program to override them. Using
    the dh_auto_configure command is better than directly invoking
    the ./configure command here since it will only override the
    --sysconfig argument and retain any other, benign arguments to
    the ./configure command.

    Si el Makefile de las fuentes de gentoo requiere la
    especificación del objetivo build para compilarlo ^[52], puedes
    añadir un objetivo override_dh_auto_build para anularlo.

    override_dh_auto_build:
            dh_auto_build -- build

    De esta forma se garantiza la ejecución de $(MAKE) con todos los
    argumentos predeterminados dados por la orden dh_auto_build y del
    argumento build.

    Si el Makefile de las fuentes de gentoo requiere la
    especificación del objetivo packageclean para limpiarlo, en lugar
    de los objetivos distclean o clean en el archivo Makefile, puedes
    añadir un objetivo override_dh_auto_clean para habilitarlo.

    override_dh_auto_clean:
            $(MAKE) packageclean

    Si el Makefile de las fuentes de gentoo contiene un objetivo test
    que no deseas que se ejecute en la construcción del paquete
    Debian, puedes usar un objetivo override_dh_auto_test sin órdenes
    para ignorarlo.

    override_dh_auto_test:

    Si gentoo contiene el poco frecuente archivo de cambios del autor
    con el nombre FIXES, dh_installchangelogs no lo instalará por
    omisión. La orden dh_installchangelogs requiere como argumento
    FIXES para instalarlo ^[53].

    override_dh_installchangelogs:
            dh_installchangelogs FIXES

    Cuando utilizas el nuevo programa dh, la utilización explícita de
    objetivos como los listados en Sección 4.4.1, “Objetivos del
    archivo rules” (excepto get-orig-source) puede dificultar la
    correcta comprensión de sus efectos exactos. Por favor, limita el
    uso de objetivos explícitos a objetivos del tipo override_dh_* y
    de forma que sean completamente independientes entre sí (siempre
    que sea posible).


---------------------------------------------------------------------

    ^[27] En este capitulo, los archivos del directorio debian se
    nombran sin el antecedente debian/ para simplificar y siempre que
    no haya posibilidad de equívocos.

    ^[28] Consulta normas de Debian, 2.4 'Secciones' y Lista de
    secciones en sid.

    ^[29] Véase Debian Policy Manual, 2.5 'Priorities'.

    ^[30] Consulta Debian Policy Manual, 7.7 'Relationships between
    source and binary packages - Build-Depends, Build-Depends-Indep,
    Build-Conflicts, Build-Conflicts-Indep'.

    ^[31] Este caso poco frecuente, está documentado en Debian Policy
    Manual, Footnotes 55. Esto se debe al funcionamiento de 
    dpkg-buildpackage, no al uso de la orden dh en el archivo debian/
    rules. Esto también se aplica al «auto build system for Ubuntu».

    ^[32] Véase Debian Policy Manual 5.6.8 "Architecture" para más
    detalles.

    ^[33] Consulta Debian Policy Manual, 7 "Declaring relationships
    between packages".

    ^[34] Las descripciones deben redactarse en inglés. Las
    traducciones de estas descripciones son proporcionados por The
    Debian Description Translation Project - DDTP.

    ^[35] Véase Developer's Reference, 6.2.5. "Version Control System
    location".

    ^[36] Si utiliza la orden dch -r para realizar este último
    cambio, asegúrese que guarda el archivo changelog explícitamente
    con el editor.

    ^[37] You can start learning how to write a Makefile from Debian
    Reference, 12.2. "Make". The full documentation is available as
    http://www.gnu.org/software/make/manual/html_node/index.html or
    as the make-doc package in the non-free archive area.

    ^[38] Debian Policy Manual, 4.9 "Main building script: debian/
    rules" explica los detalles.

    ^[39] Este objetivo es utilizado por dpkg-buildpackage como en
    Sección 6.1, “(Re)construcción completa”.

    ^[40] Este objetivo es utilizado por dpkg-buildpackage -B como en
    Sección 6.2, “Autobuilder”.

    ^[41] Este objetivo es utilizado por dpkg-buildpackage -A.

    ^[42] This uses the new debhelper v7+ features. Its design
    concepts are explained in Not Your Grandpa's Debhelper presented
    at DebConf9 by the debhelper upstream. Under lenny, dh_make
    created a much more complicated rules file with explicit rules
    and many dh_* scripts listed for each one, most of which are now
    unnecessary (and show the package's age). The new dh command is
    simpler and frees us from doing the routine work "manually". You
    still have full power to customize the process with override_dh_*
    targets. See Sección 4.4.3, “Personalización del archivo rules”.
    It is based only on the debhelper package and does not obfuscate
    the package building process as the cdbs package tends to do.

    ^[43] You can verify the actual sequences of dh_* programs
    invoked for a given target without really running them by
    invoking dh target --no-act or debian/rules -- 'target --no-act'.

    ^[44] El siguiente ejemplo presupone que su fichero debian/compat
    tiene un valor igual o superior a 9 para evitar invocar cualquier
    orden «python» automáticamente.

    ^[45] Para una descripción completa de la función de cada guión 
    dh_* y de sus opciones, lee los manuales respectivos así como la
    documentación de debhelper.

    ^[46] These commands support other build environments, such as
    setup.py, which can be listed by executing dh_auto_build --list
    in a package source directory.

    ^[47] En realidad busca el primer objetivo distclean, realclean o
    clean disponible en el Makefile y lo ejecuta.

    ^[48] En realidad busca el primero de los objetivos test o check
    en el archivo Makefile y lo ejecuta.

    ^[49] Si un paquete instala el archivo /usr/share/perl5/Debian/
    Debhelper/Sequence/nombre_personalizado.pm puedes activar la
    función adaptada con dh $@ --with nombre_personalizado.

    ^[50] Es preferible el uso de la orden dh_python2 respecto a la
    orden dh_pysupport u dh_pycentral. No uses la orden dh_python.

    ^[51] En lenny, cuando querías cambiar el comportamiento de un
    programa dh_* tenías que encontrar la línea adecuada en el
    archivo rules y cambiarla.

    ^[52] dh_auto_build sin argumentos ejecutará el primer objetivo
    del archivo Makefile.

    ^[53] Los archivos debian/changelog y debian/NEWS siempre se
    instalan automáticamente. También se busca el archivo de cambios
    del autor para cambiar el nombre a minúsculas y por su
    coincidencia con changelog, changes, changelog.txt, y
    changes.txt.

Capítulo 5. Otros ficheros en el directorio debian.

    The dh_make command had major updates since this old document was
    written. So some parts of this document aren't applicable any
    more.

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    The debmake command is used in place of the dh_make command in my
    new Guide for Debian Maintainers.

    Para controlar el trabajo de debhelper en la compilación del
    paquete, puedes añadir archivos de configuración en el directorio
    debian. En este capítulo se resumirá lo que puede hacerse con
    cada uno de ellos y su formato. Por favor, lee «Debian Policy
    Manual» y «Debian Developer's Reference» para más información.

    The dh_make command will create some template configuration files
    under the debian directory. Take a look at all of them.

    En este capitulo, los archivos del directorio debian se nombran
    sin el antecedente debian/ para simplificar y siempre que no haya
    posibilidad de equívocos.

    En otros casos, dh_make no puede construir plantillas de
    configuración para debhelper. En estos casos, deberás construir
    tu mismo los archivos con un editor.

    Si quieres utilizar estos archivos en la construcción de tu
    paquete, haz lo siguiente.

      * renombra los archivos de configuración utilizando el nombre
        del archivo del paquete binario en lugar de
        nombre_del_paquete.

      * modifica el contenido de los archivos de plantilla para
        adaptarlos a tus necesidades.
   
      * elimina aquellos archivos que no necesites.

      * realiza las modificaciones necesarias en el archivo control
        (véase Sección 4.1, “El archivo control”), si es necesario.

      * modifica el archivo rules (véase Sección 4.4, “El archivo
        rules” ), si es necesario.

    Los archivos de configuración construidos por debhelper que no
    tienen el prefijo nombre_del_paquete tales como install se
    aplicaran al primer paquete binario. Si hay varios paquetes
    binarios, sus configuraciones se especificaran con el prefijo de
    paquete binario correspondiente en su nombre: así tendrás los
    archivos paquete-1.install, paquete-2.install, etc.

5.1. Archivo README.Debian (LÉEME.debian)

    Cualquier detalle extra o discrepancias entre el programa
    original y su versión debianizada debería documentarse aquí.

    dh_make construye uno predeterminado, y éste es su aspecto:

    gentoo for Debian
    -----------------
    <possible notes regarding this package - if none, delete this file>
     -- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100

    Dado que no tenemos que poner nada aquí, elimínalo.Véase 
    dh_installdocs(1).

5.2. Archivo compat

    The compat file defines the debhelper compatibility level.
    Currently, you should set it to the debhelper v10 as follows:

    $ echo 10 > debian/compat

    You may use compat level v9 in certain circumstances for
    compatibility with older systems. However, using any level below
    v9 is not recommended and should be avoided for new packages.

5.3. Archivo conffiles

    Una de las cosas más molestas de los programas es cuando pasas
    mucho tiempo y esfuerzo adaptando un programa (como usuario) y
    una actualización destroza todos tus cambios. Debian resuelve
    este problema marcando los ficheros de configuración. ^[54] Así,
    cuando actualizas un paquete se te pregunta si deseas mantener la
    nueva configuración o no.

    Desde la versión 3 de debhelper, dh_installdeb(1) considera 
    automáticamente a todos los archivos ubicados en el directorio /
    etc como «conffiles» (archivos de configuración gestionados por
    el sistema de paquetes). Así, si todos los «conffiles» están en
    este directorio no es necesario que los incluyas en este archivo.
    Para la mayoría de paquetes, la única ubicación de los
    «conffiles» es /etc por lo que no es necesario generar este
    archivo.

    En el caso de que tu programa utilice ficheros de configuración
    pero también los reescriba él mismo es mejor no marcarlos como
    «conffiles». Si lo haces, dpkg informará a los usuarios que
    verifiquen los cambios de estos ficheros cada vez que lo
    actualicen.

    Si el programa que estás empaquetando requiere que cada usuario
    modifique los archivos de configuración del directorio /etc, hay
    dos formas para no marcarlos como archivos «conffiles» y que no
    sean manipulados por dpkg:

      * Construir un enlace simbólico de los archivos ubicados en /
        etc que apunten a archivos ubicados en el directorio /var
        generados por guiones del desarrollador («maintainer
        scripts»).

      * Poner los archivos generados por los guiones del
        desarrollador en el directorio /etc.

    Para más información sobre los guiones del desarrollador véase
    Sección 5.18, “Archivos {pre,post}{inst,rm}” .

5.4. Archivos nombre_del_paquete.cron.*

    Si tu paquete requiere tareas periódicas para funcionar
    adecuadamente, puedes usar este fichero como patrón. Puedes
    establecer la realización de tareas que se ejecuten cada hora,
    día, semana, mes, o en cualquier otro período de tiempo. Los
    nombres de los archivos son:

      * nombre_del_paquete.cron.hourly - instalados como /etc/
        cron.hourly/nombre_del_paquete: se ejecutan cada hora.

      * nombre_del_paquete.cron.daily - instalados como /etc/
        cron.daily/nombre_del_paquete: se ejecutan cada día,
        habitualmente por la mañana temprano.

      * nombre_del_paquete.cron.weekly - instalados como /etc/
        cron.weekly/nombre_del_paquete: se ejecutan cada semana,
        habitualmente en la mañana del domingo.

      * nombre_del_paquete.cron.hourly - instalados como /etc/
        cron.hourly/nombre_del_paquete: se ejecutan cada hora.

      * nombre_del_paquete.cron.d - instalados como /etc/cron.d/
        package: para cualquier otro período de tiempo.

    Para los archivos mencionados, su formato es el de guiones
    «shell». La única excepción son los archivos nombre_del_paquete
    .cron.d que deben ajustarse al formato descrito en crontab(5).

    No es necesario determinar un archivo cron.* para configurar la
    rotación de registros, para hacer eso consulta 
    dh_installlogrotate(1) y logrotate(8).

5.5. Archivo dirs

    Este fichero especifica los directorios que se necesitan pero que
    por alguna razón no se crean en un proceso de instalación normal
    (make install DESTDIR=... invocado por dh_auto_install).
    Generalmente es debido a un problema con el archivo Makefile.

    Los archivos listados en el archivo install no requieren la
    construcción previa de los directorios. Véase Sección 5.11,
    “Archivo install” .

    Es recomendable ejecutar en primer lugar la instalación y solo
    hacer uso de este archivo si se produce algún problema. No debe
    ponerse la barra inicial en los nombres de los directorios
    listados en el archivo dirs.

5.6. Archivo nombre_del_paquete.doc-base

    Si tu paquete tiene documentación además de las páginas de manual
    y de información, puedes utilizar el archivo doc-base para
    registrarla de modo que el usuario pueda encontrar esta
    documentación suplementaria con dhelp(1), dwww(1) o doccentral(1)
    .

    La documentación incluirá archivos HTML, PS y PDF ubicados en /
    usr/share/doc/nombre_del_paquete/.

    A continuación se muestra cómo es el fichero doc-base de gentoo,
    gentoo.doc-base:

    Document: gentoo
    Title: Gentoo Manual
    Author: Emil Brink
    Abstract: This manual describes what Gentoo is, and how it can be used.
    Section: File Management
    Format: HTML
    Index: /usr/share/doc/gentoo/html/index.html
    Files: /usr/share/doc/gentoo/html/*.html

    Para más información sobre el formato del archivo véase 
    install-docs(8) y el manual Debian doc-base en la copia local /
    usr/share/doc/doc-base/doc-base.html/index.html proporcionada por
    el paquete doc-base.

    Para más detalles sobre la instalación de documentación
    adicional, lee Sección 3.3, “Instalación de los archivos en su
    destino” .

5.7. Archivo docs

    Este fichero especifica los nombres de los ficheros de
    documentación que dh_installdocs(1) instalará en el directorio
    temporal.

    Por omisión, se incluirán todos los archivos existentes en los
    directorios de más alto nivel del código con los nombres BUGS,
    README*, TODO etc.

    También incluiré algunos otros para gentoo:

      BUGS
      CONFIG-CHANGES
      CREDITS
      ONEWS
      README
      README.gtkrc
      TODO

5.8. Archivo emacsen-*

    Si tu paquete proporciona ficheros Emacs que pueden ser
    compilados a bytes («bytescompile») en el momento de la
    instalación, puedes usar estos ficheros.

    El programa dh_installemacsen(1) instalará estos archivos en el
    directorio temporal .

    Elimínalos si no los necesitas.

5.9. Archivo nombre_del_paquete.examples

    La orden dh_installexamples(1) instala los archivos y directorios
    listados en este archivo como archivos de ejemplos.

5.10. Archivos nombre_del_paquete.init y nombre_del_paquete.default

    Si tu paquete es un demonio que necesita ejecutarse en el
    arranque del sistema, obviamente has desatendido mi recomendación
    inicial, ¿o no? :-)

    Please read dh_installinit(1) dh_installsystemd(1) to provide
    startup script.

    The package.default file will be installed as /etc/default/
    package. This file sets defaults that are sourced by the init
    script. This package.default file is most often used to set some
    default flags or timeouts. If your init script has certain
    configurable features, you can set them in the package.default
    file, instead of in the init script itself.

    Si el programa original incluye un archivo guión init, tu puedes
    hacer uso de él o bien descartarlo. Si optas por no hacer uso del
    guión guión init original, deberás construir uno nuevo en debian/
    nombre_del_paquete.init. En cualquier caso deberás construir los
    enlaces simbólicos rc* aunque el guión init original parezca
    correcto y se instale en el lugar adecuado. Para ello, deberás
    reescribir el objetivo dh_installinit en el archivo rules con las
    siguientes líneas:

    override_dh_installinit:
            dh_installinit --onlyscripts

    Elimina el fichero si no lo necesitas.

5.11. Archivo install

    If there are files that need to be installed into your package
    but your standard make install won't do it, put the filenames and
    destinations into this install file. They are installed by 
    dh_install(1).^[55] You should first check that there is not a
    more specific tool to use. For example, documents should be in
    the docs file and not in this one.

    El archivo install tendrá una línea para cada uno de los archivos
    a instalar, con el nombre del archivo (relativo al directorio
    superior de la compilación) seguido de un espacio y a
    continuación el directorio de instalación (relativo al directorio
    superior de instalación). Suponiendo que el archivo binario src/
    archivo_binario no se instalase, deberías utilizar el archivo
    install como sigue:

    src/archivo_binario usr/bin

    Al instalarse el paquete, se instalará el archivo binario /usr/
    bin/nombre_archivo_binario.

    En el archivo install puedes escribir el nombre del archivo sin
    el directorio de instalación siempre que no cambie la ruta
    relativa de directorio. Este formato se usa en paquetes grandes
    que separan el resultado de la compilación en múltiples paquetes
    binarios haciendo uso de nombre_del_paquete-1.install,
    nombre_del_paquete-2.install, etc.

    La orden dh_install retrocederá al directorio debian/tmp para
    buscar los archivos si no los encuentra en el directorio actual
    (o en la ubicación que hayas establecido para la búsqueda con
    --sourcedir).

5.12. Archivo nombre_del_paquete.info

    Si tu paquete utiliza páginas de información («info pages»),
    podrás instalarlas utilizando dh_installinfo(1) que utilizará el
    listado del archivo nombre_del_paquete.info.

5.13. Archivo nombre_del_paquete.links

    Si es necesario generar enlaces simbólicos adicionales, como
    responsable del paquete, en los directorios de compilación del
    paquete, puedes instalarlos utilizando dh_link(1) haciendo una
    lista de las rutas completas de los ficheros de origen y de
    destino en un fichero nombre_del_paquete.links.

5.14. Archivos {nombre_del_paquete.source/} lintian-overrides

    If lintian reports an erroneous diagnostic for a case where
    Debian policy allows exceptions to some rule, you can use package
    .lintian-overrides or source/lintian-overrides to quieten it.
    Please read the Lintian User's Manual (https://lintian.debian.org
    /manual/index.html) and refrain from abusing this.

    nombre_del_paquete.lintian-overrides es para un paquete binario
    con el nombre nombre_del_paquete y es instalado en usr/share/
    lintian/overrides/nombre_del_paquete por la orden dh_lintian.

    El archivo source/lintian-overrides es para los paquetes de
    fuentes y no se instala.

5.15. Archivos manpage.*

    El/los programa/s debería/n tener una página de manual. Tendrás
    que escribirla si no existe. La orden dh_make construye varios
    archivos de plantilla para las páginas de manual. Deberás
    copiarlos y editarlos para cada programa que no tenga página de
    manual. Asegúrate de eliminar los que no utilices.

5.15.1. Archivo manpage.1.ex

    Las páginas de manual se escriben normalmente con nroff(1). La
    plantilla manpage.1.ex está escrita con nroff. Consulta la página
    de manual man(7) para una breve descripción sobre como editar el
    archivo.

    El nombre del archivo de manual debería incluir el nombre del
    programa que está documentando, así que lo renombraremos de
    manpage a gentoo. El nombre del fichero incluye también .1 como
    primer sufijo, lo que significa que es una página de manual para
    una programa de usuario. Asegúrate de verificar que esa sección
    es la correcta. Aquí tienes una pequeña lista de las secciones de
    las páginas de manual.

    
    +---------------------------------------------------------------+
    |Sección|    Descripción    |               Notas               |
    |-------+-------------------+-----------------------------------|
    |1      |Órdenes de usuario |Órdenes ejecutables o guiones      |
    |-------+-------------------+-----------------------------------|
    |2      |Llamadas del       |Funciones proporcionadas por el    |
    |       |sistema            |núcleo                             |
    |-------+-------------------+-----------------------------------|
    |3      |Llamadas a         |Funciones de las bibliotecas del   |
    |       |bibliotecas        |sistema                            |
    |-------+-------------------+-----------------------------------|
    |4      |Archivos especiales|Por lo general se encuentran en /  |
    |       |                   |dev                                |
    |-------+-------------------+-----------------------------------|
    |5      |Formatos de archivo|p. ej. el formato de /etc/passwd   |
    |-------+-------------------+-----------------------------------|
    |6      |Juegos             |Juegos y otros programas de        |
    |       |                   |entretenimiento                    |
    |-------+-------------------+-----------------------------------|
    |7      |Paquetes macro     |Tales como macros man              |
    |-------+-------------------+-----------------------------------|
    |8      |Administración del |Programas que sólo suele ejecutar  |
    |       |sistema            |el superusuario                    |
    |-------+-------------------+-----------------------------------|
    |9      |Rutinas del núcleo |Llamadas al sistema no estándar e  |
    |       |                   |internas                           |
    +---------------------------------------------------------------+

    Así que la página de manual de gentoo debería nombrarse como
    gentoo.1. No había una página de manual gentoo.1 en el paquete
    fuente así que la escribí renombrando la plantilla manpage.1.ex
    como gentoo.1 y modificándola usando la información del ejemplo y
    de los documentos del programador original.

    Utiliza la orden help2man para generar la página de manual a
    partir de la información dada por «--help» y --version» para cada
    programa ^[56].

5.15.2. Archivo manpage.sgml.ex

    Por otro lado, puede que prefieras escribir usando SGML en lugar
    de nroff. En este caso, puedes usar la plantilla manpage.sgml.ex.
    Si haces esto, tendrás que:

      * renombrar el fichero a algo como gentoo.sgml.

      * instalar el paquete docbook-to-man

      * añadir docbook-to-man en el campo Build-Depends en el archivo
        control
   
      * añadir el objetivo override_dh_auto_build en el fichero
        rules:

        override_dh_auto_build:
                docbook-to-man debian/gentoo.sgml > debian/gentoo.1
                dh_auto_build

5.15.3. Archivo manpage.xml.ex

    Si prefieres el formato XML en lugar de SGML, puedes utilizar la
    plantilla manpage.xml.ex. En este caso debes:

      * renombrar el archivo a gentoo.1.xml

      * instalar el paquete docbook-xsl y un procesador XSLT como
        xsltproc (recomendado)

      * añadir los paquetes docbook-xsl, docbook-xml y xsltproc en la
        línea de Build-Depends en el fichero de control

      * añadir el objetivo override_dh_auto_build en el fichero rules:
   
        override_dh_auto_build:
                xsltproc --nonet \
                 --param make.year.ranges 1 \
                 --param make.single.year.ranges 1 \
                 --param man.charmap.use.subset 0 \
                 -o debian/ \
        http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
                debian/gentoo.1.xml
                dh_auto_build

5.16. Archivo nombre_del_paquete.manpages

    Si tu paquete tiene páginas de manual, deberías instalarlas con 
    dh_installman(1) listando los archivos correspondientes en el
    archivo nombre_del_paquete.manpages.

    Para instalar el archivo docs/gentoo.1 del paquete gentoo como su
    manual, construirás el archivo gentoo.manpages con el contenido:

    docs/gentoo.1

5.17. Archivo NEWS

    La orden dh_installchangelogs(1) instala este archivo.

5.18. Archivos {pre,post}{inst,rm}

    Los archivos postinst, preinst, postrm y prerm ^[57] se denominan
    guiones del desarrollador. Son guiones que se colocan en el área
    de control del paquete y que dpkg ejecuta cuando tu paquete se
    instala, se actualiza o se elimina.

    Por ahora, deberías intentar evitar editar manualmente estos 
    guiones del desarrollador si puedes porque suelen hacerse muy
    complejos. Para más información lee «Debian Policy Manual, 6
    "Package maintainer scripts and installation procedure"», y echa
    un vistazo a los ejemplos proporcionados por dh_make.

    Si a pesar de mis advertencias, adaptas los guiones del
    desarrollador para el paquete, asegúrate de comprobar su
    funcionamiento no sólo para la instalación y actualización del
    paquete, sino también para su desinstalación y eliminación
    completa.

    Las actualizaciones a una nueva versión deben ser «silenciosas» y
    no intrusivas. Los usuarios no deberían darse cuenta de la
    actualización, salvo quizás para descubrir que se han arreglado
    errores antiguos y porque hay alguna nueva funcionalidad.

    Cuando la actualización es necesariamente intrusiva (p.e.
    archivos de configuración dispersos en varios directorios con una
    estructura totalmente modificada), se deberían establecer los
    valores predeterminados seguros (p.e. desactivar los servicios) y
    facilitar la documentación apropiada establecida por las normas
    (archivos README.Debian y NEWS.Debian) como último recurso. Hay
    que evitar molestar al usuario con notas debconf invocadas por
    los guiones del desarrollador en las actualizaciones.

    El paquete ucf facilita el sistema conffile-like para preservar
    los cambios de configuración realizados por el usuario y por ello
    no deben nombrarse como conffiles los archivos manejados por los 
    guiones del desarrollador. Así se minimizan las incidencias
    asociadas con ellos.

    Estos guiones del desarrollador son un ejemplo de las
    características de Debian que explican por qué la gente elige
    Debian. Debes ser cuidadoso con no molestarles con ellos.

5.19. Archivo nombre_del_paquete.symbols

    Packaging of a library is not easy for a novice maintainer and
    should be avoided. Having said it, if your package has libraries,
    you should have debian/package.symbols files. See Sección A.2,
    “Gestionando debian/package.symbols”.

5.20. Archivo TODO

    La orden dh_installdocs(1) instala este archivo.

5.21. Archivo watch

    The watch file format is documented in the uscan(1) manpage. The
    watch file configures the uscan program (in the devscripts
    package) to watch the site where you originally got the source.
    This is also used by the Debian Package Tracker service.

    Este es su contenido:

    # watch control file for uscan
    version=3
    http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate

    Con el archivo watch, la URL http://sf.net/gentoo se descarga y
    se buscan los enlaces del tipo <a href=...>. El nombre base
    (justo la parte después del / final) de las direcciones URL
    enlazadas se comparan con la expresión regular de Perl (véase 
    perlre(1)) con el patrón gentoo-(.+)\.tar\.gz. Se descarga el
    archivo de versión más reciente de entre todos los archivos
    encontrados cuyo nombre se ajuste al patrón, y se ejecutará el
    programa uupdate para construir el árbol de código fuente
    actualizado en base a este fichero.

    Although this is true for other sites, the SourceForge download
    service at http://sf.net is an exception. When the watch file has
    a URL matching the Perl regexp ^http://sf\.net/, the uscan
    program replaces it with http://qa.debian.org/watch/sf.php/ and
    then applies this rule. The URL redirector service at http://
    qa.debian.org/ is designed to offer a stable redirect service to
    the desired file for any watch pattern of the form http://sf.net/
    project/tar-name-(.+)\.tar\.gz. This solves issues related to
    periodically changing SourceForge URLs.

    Si el autor publica la firma criptográfica del fichero tarball,
    se recomienda comprobar su autenticidad utilizando la opción
    pgpsigurlmangle descrita en uscan(1).

5.22. Archivo source/format

    El archivo debian/source/format, solo contendrá una línea
    indicando el formato deseado para el paquete (véase dpkg-source
    (1) para consultar la lista completa). Después de squeeze debería
    ser:

      * 3.0 (native) para paquetes nativos de Debian o
   
      * 3.0 (quilt) para el resto de paquetes.

    El nuevo formato 3.0 (quilt) registra los cambios en series de
    archivos de parches quilt en el directorio debian/patches. Estos
    cambios se aplican automáticamente en la extracción de las
    fuentes del paquete ^[58]. Las modificaciones se guardan en el
    archivo debian.tar.gz que contiene todos los archivos del
    directorio debian utilizado en la construcción del paquete. El
    nuevo formato permite la inclusión de archivos como los iconos
    PNG sin necesidad de trucos ^[59].

    Cuando dpkg-source extrae un paquete fuente con el formato 3.0
    (quilt), automáticamente aplica todos los parches listados en el
    archivo debian/patches/series. Puedes evitar la ejecución de los
    parches al final de la extracción con la opción --skip-patches.

5.23. Archivo source/local-options

    When you want to manage Debian packaging activities under a VCS,
    you typically create one branch (e.g., upstream) tracking the
    upstream source and another branch (e.g., typically master for
    Git) tracking the Debian package. For the latter, you usually
    want to have unpatched upstream source with your debian/* files
    for the Debian packaging to ease merging of the new upstream
    source.

    Una vez compilado el paquete, las fuentes estarán parcheadas.
    Deberás deshacer los parches manualmente ejecutando dquilt pop -a
    antes de sincronizar con la rama master. Puedes automatizar esto
    añadiendo el archivo opcional debian/source/local-options cuyo
    contenido será «unapply-patches». Este archivo no se incluye en
    el paquete fuente generado y sólo cambia el entorno local de
    compilación. Este archivo también puede contener la línea
    «abort-on-upstream-changes» (véase dpkg-source(1)).

    unapply-patches
    abort-on-upstream-changes

5.24. Archivo source/options

    Los archivos generados automáticamente en el árbol del código
    fuente pueden ser bastante molestos en la construcción del
    paquete debido a que generan archivos de parche grandes. Hay
    módulos personalizados, tales como dh_autoreconf para aliviar
    este problema como se describe en Sección 4.4.3, “Personalización
    del archivo rules”.

    Puedes proporcionar una expresión regular en Perl para la opción
    --extend-diff-ignore del argumento de dpkg-source(1) para hacer
    caso omiso de los cambios realizados en los archivos generados
    automáticamente al crear el paquete fuente.

    Puedes conservar las opciones de la orden dpkg-source en el
    archivo source/options de las fuentes del paquete como solución
    genérica al problema de los archivos autogenerados. En el ejemplo
    siguiente, se evita la generación de archivos de parche para
    config.sub config.guess y Makefile.

    extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"

5.25. Archivos patches/*

    El antiguo formato 1.0 construía un archivo diff.gz cuyo
    contenido era el de los archivos de construcción del paquete del
    directorio debian así como los cambios a realizar en las fuentes.
    Este formato para conservar los cambios resultaba engorroso
    cuando se trataba de inspeccionar y entender cada modificación de
    las fuentes. Ya no resulta eficaz.

    El nuevo formato 3.0 (quilt) de las fuentes, guarda las
    modificaciones (los parches) en archivos en el directorio debian/
    patches/* utilizando la orden quilt. Estos parches y otros datos
    del paquete que están en el directorio debian se conservan en el
    archivo debian.tar.gz. Desde que la orden dpkg-source puede
    aplicar los parches en las fuentes con el nuevo formato tipo 
    quilt sin el paquete quilt, no es necesario añadir el paquete
    quilt en el campo Build-Depends del fichero control ^[60].

    El funcionamiento de la orden quilt se explica en quilt(1).
    Conserva las modificaciones de las fuentes en una colección de
    archivos de parches -p1 en el directorio debian/patches y las
    fuentes originales permanecen sin modificar fuera del directorio
    debian. El orden de aplicación de las modificaciones se conserva
    en el archivo debian/patches/series. Puedes aplicar («push»),
    deshacer («pop») y actualizar las modificaciones fácilmente ^[61]
    .

    En Capítulo 3, Modificar las fuentes, se han construido tres
    archivos de parches en debian/patches.

    Puesto que los parches se ubican en debian/patches, asegúrate que
    has configurado adecuadamente la orden dquilt como se describe en
    Sección 3.1, “Configurar quilt” .

    Cuando alguien (incluido tú mismo), facilita un parche
    nombre_parche.patch para las fuentes, cuando ya está construido
    el paquete, la modificación de un paquete con formato 3.0 (quilt)
    es así de simple:

    $ dpkg-source -x gentoo_0.9.12.dsc
    $ cd gentoo-0.9.12
    $ dquilt import ../nombre_parche.patch
    $ dquilt push
    $ dquilt refresh
    $ dquilt header -e
    .. descripción de la modificación

    Los parches conservados con el nuevo formato de fuentes 3.0
    (quilt) deben estar exentos de cosas innecesarias. Debes
    asegurarte ejecutando dquilt pop -a; while dquilt push; do dquilt
    refresh; done.


---------------------------------------------------------------------

    ^[54] Véase dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles".

    ^[55] Esto reemplaza la orden obsoleta dh_movefiles(1) que se
    configuraba con el archivo files.

    ^[56] Ten presente que el marcador de posición de páginas de
    manual help2man reclamará que la documentación más detallada se
    encuentra disponible en el sistema de información. Si el comando
    no encuentra una página info, deberás editar manualmente la
    página de manual construida por help2man.

    ^[57] Aunque el texto utilice la expresión abreviada bash para el
    nombre de los archivos {pre,post}{inst,rm}, debes utilizar la
    sintaxis POSIX pura para estos guiones del desarrollador para
    mantener la compatibilidad con el «shell» del sistema dash.

    ^[58] Véase DebSrc3.0 para un resumen informativo sobre los
    formatos 3.0 (quilt) y 3.0 (native).

    ^[59] Actualmente, este nuevo formato también permite trabajar
    con múltiples archivos «tar» fuente y otros sistemas de
    compresión. Estas funciones están fuera del objetivo de este
    documento.

    ^[60] Se han propuesto y se están utilizando otros métodos de
    aplicación de los parches en Debian. El sistema quilt es el
    preferido. Otros sistemas son dpatch, dbs, cdbs, etc. La mayoría
    de ellos conservan los parches en archivos en el directorio
    debian/patches/*.

    ^[61] Si has solicitado a un patrocinador que transfiera el
    paquete al repositorio, este sistema de separación y
    documentación de los cambios es muy importante para facilitar la
    revisión del paquete por el patrocinador.

Capítulo 6. Construcción del paquete

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Ahora deberíamos estar preparados para construir el paquete.

6.1. (Re)construcción completa

    Para realizar correctamente la (re)compilación completa de un
    paquete, debes asegurarte que tienes instalados:

      * el paquete build-essential.

      * los paquetes listados en el campo Build-Depends del archivo
        «control» (Sección 4.1, “El archivo control” ), y

      * los paquetes listados en el campo Build-Depends-indep
        (también del archivo «control», Sección 4.1, “El archivo
        control”).

    Después ejecuta la siguiente orden en el directorio raíz del
    código fuente del programa:

    $ dpkg-buildpackage -us -uc

    Esto hará todo lo necesario para construir los paquetes binarios
    y de fuentes para ti. Para ello:

      * limpia el árbol del código fuente («debian/rules clean»)

      * construye el paquete de código («dpkg-source -b»)

      * construye el programa («debian/rules build»)
   
      * construye el paquete binario (fakeroot debian/rules binary)

      * genera el fichero .dsc

      * genera el fichero .changes, utilizando dpkg-genchanges

    If the build result is satisfactory, sign the .dsc and .changes
    files with your private GPG key using the debsign command. You
    need to enter your secret pass phrase, twice. ^[62]

    Para los paquetes no nativos Debian, p.ej, gentoo, podrás ver los
    siguientes archivos en el directorio padre (~/gentoo) después de
    construir el paquete:

      * gentoo_0.9.12.orig.tar.gz

        This is the original upstream source code tarball, merely
        renamed to the above so that it adheres to the Debian
        standard. Note that this was created initially by the command
        dh_make -f ../gentoo-0.9.12.tar.gz.

      * gentoo_0.9.12-1.dsc

        Este es un sumario de los contenidos del código fuente. Este
        fichero se genera a partir del fichero de control y se usa
        cuando se descomprimen las fuentes con dpkg-source(1).

      * gentoo_0.9.12-1.debian.tar.gz

        Este fichero comprimido contiene el directorio debian
        completo. Todas las modificaciones de las fuentes originales
        se conservan en los archivos de parches quilt en el
        directorio debian/patches.

        Si alguien quiere volver a construir tu paquete desde cero,
        puede hacerlo fácilmente usando los tres ficheros de arriba.
        El proceso de extracción es trivial: sólo se debe copiar los
        tres ficheros en algún lado y ejecutar dpkg-source -x
        gentoo_0.9.12-1.dsc ^[63].

      * gentoo_0.9.12-1_i386.deb

        Este es el paquete binario completo. Puedes usar dpkg para
        instalar o eliminar tanto este paquete como cualquier otro.

      * gentoo_0.9.12-1_i386.changes

        Este fichero describe todos los cambios hechos en la revisión
        actual del paquete, y lo utilizan los programas de
        mantenimiento del archivo FTP de Debian para instalar los
        paquetes binarios y fuentes. Se genera parcialmente a partir
        del fichero changelog y el fichero .dsc.

        Mientras sigues trabajando en el paquete, éste cambiará su
        comportamiento y se le añadirán nuevas funciones. Las
        personas que descarguen tu paquete pueden leer este fichero y
        ver qué ha cambiado. Los programas de mantenimiento del
        archivo de Debian, también enviarán el contenido de este
        fichero a la lista de correo
        debian-changes-announce@lists.debian.org.

    The gentoo_0.9.12-1.dsc and gentoo_0.9.12-1_i386.changes files
    must be signed using the debsign command with your private GPG
    key in the ~/.gnupg/ directory, before uploading them to the
    Debian FTP archive. The GPG signature provides the proof that
    these files are really yours, using your public GPG key.

    The debsign command can be made to sign with your specified
    secret GPG key ID (good for sponsoring packages) with the
    following in the ~/.devscripts file:

    DEBSIGN_KEYID=Tu_GPG_keyID

    Las largas listas de números en los ficheros .dsc y .changes son
    las sumas MD5/SHA1/SHA256 de los ficheros incluidos en el
    paquete. Las personas que descarguen estos ficheros pueden
    comprobarlos con md5sum(1), sha1sum(1) o sha256sum(1) y si los
    números no coinciden, sabrán que el fichero está corrupto o ha
    sido modificado.

6.2. Autobuilder

    Debian mantiene diversas adaptaciones «ports» con la red de
    servidores de compilación automática que ejecuta demonios buildd
    en ordenadores con diferentes arquitecturas. Aunque no deberás
    hacer todo esto tú mismo, debes conocer el proceso al que se verá
    sometido tu paquete. Veamos cómo se procesa el paquete para
    compilarlo en diversas arquitecturas ^[64].

    Los paquetes del tipo Architecture: any, son construidos por el
    sistema de compilación automática. El sistema garantiza la
    instalación de:

      * el paquete build-essential, y
   
      * los paquetes listados en el campo Build-Depends (véase
        Sección 4.1, “El archivo control” ).

    A continuación se ejecuta la siguiente orden en el directorio de
    las fuentes:

    $ dpkg-buildpackage -B

    De esta manera, se ejecuta todo lo necesario para construir el
    paquete binario dependiente de la arquitectura en cada
    arquitectura. Hace lo siguiente:

      * limpia el árbol del código fuente («debian/rules clean»)

      * construye el programa («debian/rules build»)

      * construye el paquete binario para la arquitectura (fakeroot
        debian/rules binary-arch)

      * firma el fichero fuente .dsc, usando gpg

      * genera y firma el fichero de envío .changes, usando 
        dpkg-genchanges y gpg

    Esta es la razón por la que el paquete estará disponible para
    otras arquitecturas.

    Aunque es necesario instalar los paquetes listados en el campo
    Build-Depends-indep para el empaquetamiento normal (véase
    Sección 6.1, “(Re)construcción completa” ), el sistema automático
    de construcción no lo requiere puesto que solo construye paquetes
    binarios dependientes de la arquitectura ^[65]. Estas diferencias
    entre el empaquetamiento normal y el automático determinan si los
    paquetes requeridos para la compilación se deben listar en el
    campo Build-Depends o bien en el campo Build-Depends-indep del
    archivo debian/control (véase Sección 4.1, “El archivo control”
    ).

6.3. La orden debuild

    Puedes automatizar aún más el proceso de construcción de paquetes
    de la orden dpkg-buildpackage con la orden debuild. Véase debuild
    (1).

    The debuild command executes the lintian command to make a static
    check after building the Debian package. The lintian command can
    be customized with the following in the ~/.devscripts file:

    DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
    DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"

    Por ejemplo, limpiar el código y reconstruir el paquete desde una
    cuenta de usuario es tan simple como:

    $ debuild

    Puedes eliminar los archivos generados en la compilación
    ejecutando:

    $ debuild -- clean

6.4. El paquete pbuilder

    El paquete pbuilder es muy útil para conseguir un entorno de
    compilación limpio (chroot) donde verificar las dependencias de
    compilación ^[66]. Esto asegura una construcción limpia desde el
    código en los auto-compiladores de sid para las distintas
    arquitecturas y evita fallos de nivel de severidad serios del
    tipo FTBFS («Fail to Build From Source», o «fallo al construir
    desde la fuente »), que son siempre de categoría RC (fallos
    críticos o «release critical»). ^[67]

    Para personalizar el funcionamiento del paquete pbuilder haz lo
    siguiente:

      * permite que tu usuario del sistema tenga permiso de escritura
        en el directorio /var/cache/pbuilder/result.

      * crea un directorio, p.e. /var/cache/pbuilder/hooks, con
        permiso de escritura para tu usuario. En este directorio
        pondrás los guiones «hook»

      * establece los archivos ~/.pbuilderrc o /etc/pbuilderrc con el
        siguiente contenido:

        AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
        HOOKDIR=/var/cache/pbuilder/hooks

    Ahora puedes inicializar el sistema local pbuilder chroot por
    primera vez ejecutando:

    $ sudo pbuilder create

    Si ya dispones de un paquete fuente completo, ejecuta las
    siguientes órdenes en el directorio donde tengas los archivos
    nombre_del_paquete.orig.tar.gz, nombre_del_paquete.debian.tar.gz
    y nombre_del_paquete.dsc para actualizar el sistema local
    pbuilder chroot y, a continuación, compilar el paquete binario en
    él:

    $ sudo pbuilder --update
    $ sudo pbuilder --build nombre_del_paquete.dsc

    Una vez finalizada la compilación, el paquete compilado estará en
    el directorio /var/cache/pbuilder/result/ cuyo propietario será
    tu usuario en lugar del usuario administrador.

    Las firmas GPG en los archivos .dsc y .changes se puede generar
    como sigue

    $ cd /var/cache/pbuilder/result/
    $ debsign nombre_del_paquete_versión_arquitectura.changes

    Si en lugar de iniciar la construcción del paquete a partir de un
    paquete ya construido, dispones de un directorio con las fuentes
    originales actualizadas, deberás ejecutar las siguientes órdenes
    desde el directorio de las fuentes originales (y en el que deberá
    estar presente el directorio debian con todo su contenido):

    $ sudo pbuilder --update
    $ pdebuild

    Puedes «conectarte» al entorno chroot ejecutando la orden
    pbuilder --login --save-after-login y configurarlo para adaptarlo
    a tus necesidades. Este entorno puede guardarse saliendo del
    «shell» con ^D (Control-D).

    La última versión de la orden lintian puede ejecutarse
    automáticamente en el entorno chroot utilizando el guión «hook»
    disponible en /var/cache/pbuilder/hooks/B90lintian y configurado
    como sigue ^[68]:

    #!/bin/sh
    set -e
    install_packages() {
            apt-get -y --allow-downgrades install "$@"
            }
    install_packages lintian
    echo "+++ lintian output +++"
    su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
    # use this version if you don't want lintian to fail the build
    #su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
    echo "+++ end of lintian output +++"

    Debes tener un entorno sid actualizado para construir
    correctamente paquetes para sid. En realidad, al versión sid
    puede contener errores que no hacen recomendable la migración de
    tu sistema a esta versión. El paquete pbuilder te ayuda a hacer
    frente a esta situación.

    You may need to update your stable packages after their release
    for stable-proposed-updates, stable/updates, etc. ^[69] For such
    occasions, the fact that you may be running a sid system is not a
    good enough excuse for failing to update them promptly. The
    pbuilder package can help you to access environments of almost
    any Debian derivative distribution of the same architecture.

    Consulta http://www.netfort.gr.jp/~dancer/software/pbuilder.html,
    pdebuild(1), pbuilderrc(5), y pbuilder(8).

6.5. git-buildpackage command and similar

    Si el autor original utiliza un sistema de gestión de versiones
    para el código ^[70] puedes considerar utilizarlo. Así se
    facilita la coordinación y la selección de los parches en las
    fuentes. Debian dispone de varios paquetes de guiones
    especializados en cada tipos de VCS:

      * git-buildpackage: conjunto para la compilación de paquetes en
        repositorios «Git».

      * svn-buildpackage: programas de ayuda para el mantenimiento de
        paquetes Debian con «Subversion».

      * cvs-buildpackage: conjunto de paquete de guiones Debian para
        estructuras de directorios CVS.

    El uso de git-buildpackage se está convirtiendo en muy popular
    para los desarrolladores de Debian para el mantenimiento de los
    paquetes Debian con el servidor Git en alioth.debian.org. ^[71]
    Este paquete ofrece muchas órdenes para automatizar el
    mantenimiento de paquetes:

      * gbp-import-dsc(1): import a previous Debian package to a Git
        repository.

      * gbp-import-orig(1): import a new upstream tar to a Git
        repository.

      * gbp-dch(1): generate the Debian changelog from Git commit
        messages.

      * git-buildpackage(1): compila los paquetes Debian del
        repositorio «Git».

      * git-pbuilder(1): compila los paquetes Debian del repositorio
        «Git» utilizando pbuilder/cowbuilder.

    Estas órdenes utilizan 3 ramas en la gestión del proceso de
    empaquetado:

      * main (principal) del árbol de directorios del paquete Debian.

      * upstream (autor) para el árbol de las fuentes del autor.

      * pristine-tar por el fichero comprimido «.tar» del autor
        generado por la opción --pristine-tar.^[72]

    Puedes configurar git-buildpackage con ~/.gbp.conf. Lee gbp.conf
    (5). ^[73]

6.6. Reconstrucción rápida

    Con un paquete grande, puede que no quieras recompilar desde cero
    cada vez que tocas un detalle en el fichero debian/rules. Para
    propósitos de prueba, puedes hacer un fichero .deb sin necesidad
    de recompilar las fuentes originales de esta forma^[74]:

      fakeroot debian/rules binary

    O simplemente puedes comprobar si el paquete se compila con:

    $ fakeroot debian/rules build

    Una vez terminada la puesta a punto, recuerda reconstruir el
    paquete siguiendo el procedimiento adecuado explicado
    anteriormente. Puede que no seas capaz de enviar correctamente el
    paquete si intentas enviar los archivos .deb construidos de esta
    forma.

6.7. Jerarquía de órdenes

    A continuación hay un breve resumen de cómo las órdenes de
    construcción de paquetes encajan jerárquicamente. Hay muchas
    maneras de hacer lo mismo.

      * debian/rules = guión del desarrollador para la construcción
        del paquete

      * dpkg-buildpackage = orden principal de las herramientas de
        compilación

      * debuild = dpkg-buildpackage + lintian (construcción con la
        configuración estándar de las variables de entorno)

      * pbuilder = núcleo de la herramienta de entorno «chroot» de
        Debian
   
      * pdebuild = pbuilder + dpkg-buildpackage (construcción en el
        entorno «chroot»"

      * cowbuilder = ejecución acelerada de pbuilder

      * git-pbuilder = la versión de sintaxis fácil para pdebuild
        (utilizado por gbp buildpackge)

      * gbp = gestor de los ficheros Debian del paquete en un
        repositorio «git»

      * gbp buildpackge = pbuilder + dpkg-buildpackage + gbp

    Aunque el uso de las órdenes de nivel superior como gbp
    buildpackge y pbuilder asegura el entorno perfecto de
    construcción de paquetes, es esencial para comprender cómo
    órdenes de menor nivel, tales como debian/rules y 
    dpkg-buildpackage se ejecutan subordinadas.


---------------------------------------------------------------------

    ^[62] Esta clave GPG debe ser firmado por un desarrollador de
    Debian para conectarse a la red de confianza y debe registrarse
    en el anillo de claves de Debian. Esto permite que los paquetes
    sean aceptados en los repositorios de Debian. Consulta Cómo crear
    un clave GPG nueva y Wiki de Debian sobre la firma de claves.

    ^[63] Puedes evitar la aplicación automática de las
    modificaciones por dquilt en los paquetes con formato 3.0 (quilt)
    al final de la extracción con la opción --skip-patches. También
    puedes deshacer las modificaciones al finalizar la extracción con
    la ejecución de dquilt pop -a.

    ^[64] El funcionamiento del sistema actual de compilación
    automática es más complicado que lo expuesto en este documento.
    Muchos detalles quedan fuera de los objetivos de este documento.

    ^[65] Contrariamente al modo de funcionamiento del paquete
    pbuilder (que se tratará más adelante), el entorno chroot del
    paquete sbuild utilizado por el sistema automático no tiene una
    instalación mínima de paquetes del sistema y puede dejar muchos
    paquetes instalados.

    ^[66] Dado que el paquete pbuilder está evolucionando, deberías
    comprobar la situación de la configuración consultando la última
    documentación oficial disponible.

    ^[67] Consulta http://buildd.debian.org/ para saber más sobre la
    construcción automática de paquetes Debian.

    ^[68] Se supone que la variable de entorno HOOKDIR=/var/cache/
    pbuilder/hooks ya está configurada. Puedes consultar otros
    ejemplos en /usr/share/doc/pbuilder/examples.

    ^[69] Hay algunas restricciones para estas actualizaciones de tu
    paquete stable.

    ^[70] Consulta Version control systems para saber más.

    ^[71] Debian wiki Alioth documenta cómo utilizar el servicio
    alioth.debian.org.

    ^[72] The --pristine-tar option invokes the pristine-tar command,
    which can regenerate an exact copy of a pristine upstream tarball
    using only a small binary delta file and the contents of the
    tarball that are typically kept in an upstream branch in the VCS.

    ^[73] Aquí tienes algunos recursos disponibles en la red,
    dirigidos a usuarios expertos.

      * Construcción paquetes Debian con «git-buildpackage» (/usr/
        share/doc/git-buildpackage/manual-html/gbp.html)

      * debian packages in git

      * Using Git for Debian Packaging

      * git-dpm: Debian packages in Git manager

    ^[74] Environment variables that are normally configured to
    proper values are not set by this method. Never create real
    packages to be uploaded using this quick method.

Capítulo 7. Comprobación del paquete en busca de fallos

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Debes conocer varios métodos para comprobar el paquete y
    localizar errores antes de transferirlo a repositorios públicos.

    Probar el paquete en una máquina distinta a la usada en su
    construcción es una magnífica idea. Debes poner atención en todos
    los avisos y errores que se produzcan en las pruebas explicadas a
    continuación.

7.1. Cambios sospechosos

    Si encuentras un nuevo archivo de parche autogenerado con el
    nombre debian-changes-* en el directorio debian/patches después
    de la construcción de tu paquete de Debian no nativo en formato
    3.0 (quilt), es probable que hayas cambiado algún archivo
    accidentalmente o bien que el guión de compilación haya
    modificado las fuentes originales. Si el error es tuyo,
    corrígelo. Si es causado por el guión de compilación, corrige el
    origen del error con dh-autoreconf como en Sección 4.4.3,
    “Personalización del archivo rules” o bien inténtalo con los
    archivos source/options como en Sección 5.24, “Archivo source/
    options”.

7.2. Comprobación de la instalación del paquete

    You must test your package for whether it installs without
    problems. The debi(1) command helps you to test installing all
    the generated binary packages.

    $ sudo debi gentoo_0.9.12-1_i386.changes

    To prevent installation problems on different systems, you must
    make sure that there are no filenames conflicting with other
    existing packages, using the Contents-i386 file downloaded from
    the Debian archive. The apt-file command may be handy for this
    task. If there are collisions, please take action to avoid this
    real problem, whether by renaming the file, moving a common file
    to a separate package that multiple packages can depend on, using
    the alternatives mechanism (see update-alternatives(1)) in
    coordination with the maintainers of other affected packages, or
    declaring a Conflicts relationship in the debian/control file.

7.3. Comprobación de los guiones del desarrollador («maintainer
scripts»)

    Ya se ha comentado que los guiones del desarrollador (los
    archivos preinst, prerm, postinst y postrm) son complicados,
    excepto si se utilizan los generados por el paquete debhelper. No
    se recomienda su utilización a los desarrolladores principiantes
    (véase Sección 5.18, “Archivos {pre,post}{inst,rm}” ).

    Si el paquete utiliza estos guiones del desarrollador modificados
    o no triviales, debes comprobar su funcionamiento en la
    instalación, desinstalación, eliminación y actualización. Algunos
    errores en estos guiones del desarrollador sólo se producen
    cuando los paquetes se eliminan o purgan. Utiliza la orden dpkg
    como se indica a continuación para probarlos:

    $ sudo dpkg -r gentoo
    $ sudo dpkg -P gentoo
    $ sudo dpkg -i gentoo_versión-revisión_i386.deb

    Sigue esta secuencia para la comprobación:

      * Instala la versión anterior del paquete (requerido).

      * Actualiza ahora a la versión actual.

      * Vuelve a la versión anterior (opcional).

      * Elimínalo.
   
      * Instala la nueva versión del paquete.

      * Elimínalo.

      * Instálalo de nuevo.

      * Elimínalo.

    Si estás trabajando en la construcción de la primera versión del
    paquete, construye versiones «fantasma» anteriores (será
    suficiente cambiar el número de la versión) para realizar las
    pruebas y así prevenir problemas.

    Recuerda que si ya hay versiones anteriores del paquete en el
    repositorio Debian, los usuarios actualizarán el paquete desde la
    versión anterior disponible (y esta versión puede ser distinta en
    la versión estable y de pruebas). Realiza las comprobaciones
    también con estas versiones.

    Aunque no se garantiza la reinstalación de una versión anterior,
    es preferible asegurarse que es posible sin generar problemas.

7.4. El paquete lintian

    Ejecuta lintian(1) en tu archivo .changes. La orden lintian
    ejecutará varios guiones para revisar los errores más frecuentes
    de los paquetes ^[75].

    $ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes

    Por supuesto, cambia el nombre del fichero por el nombre del
    fichero .changes generado por tu paquete. Los mensajes de error
    de lintian se codifican con una letra al inicio de la línea del
    mensaje:

      * E: para los errores; indica violaciones de las normas o un
        error en el paquete.

      * W: para las advertencias; indica una posible violación de las
        normas o error en el paquete (pero pudiendo ser una falsa
        alarma).

      * I: para información; proporciona algo de información sobre
        algún aspecto del paquete (que tal vez sea mejorable).

      * N: para las notas o anotaciones; proporciona mensajes
        detallados que pueden ayudarte en la depuración del paquete.

      * O: para mensajes ignorados; un mensaje ignorado (según lo
        configurado en los archivos lintian-overrides pero que se
        emite debido a la opción --show-overrides.

    En el caso de los errores (líneas que comienzan por E:), lee la
    explicación (líneas N:), cambia el paquete para eliminarlos o
    verifica que los avisos son falsos. En este caso, genera los
    archivos lintian-overrides como se ha descrito en Sección 5.14,
    “Archivos {nombre_del_paquete.source/} lintian-overrides”.

    Observa que puedes construir el paquete con dpkg-buildpackage y
    ejecutar lintian todo con sólo una orden si utilizas debuild(1) o
    pdebuild(1).

7.5. La orden debc

    Puedes ver la lista de archivos del paquete binario Debian
    ejecutando la orden debc(1) como sigue:

    $ debc nombre_del_paquete.changes

7.6. La orden debdiff

    Puedes comparar el contenido de dos paquetes de fuentes Debian
    ejecutando la orden debdiff(1) como sigue:

    $ debdiff versión_anterior.dsc nueva_versión.dsc

    Puedes comparar la lista de ficheros de dos paquetes binarios de
    Debian con la orden debdiff(1) ejecutando la orden como sigue:

    $ debdiff versión_anterior.changes nueva_versión.changes

    Este programa es útil para verificar que no hay ficheros que se
    hayan cambiado de sitio o eliminado por error, y que no se ha
    realizado ningún otro cambio no deseado al actualizar el paquete.

7.7. La orden interdiff

    Puedes comparar dos ficheros diff.gz con la orden interdiff(1).
    Esto es muy útil para verificar que no se han realizado cambios
    inadvertidos por el responsable del paquete al actualizar el
    paquetes que se han construido con el formato 1.0. Ejecuta lo
    siguiente:

    $ interdiff -z versión_anterior.diff.gz nueva_versión.diff.gz

    El nuevo formato de fuentes 3.0 conserva los cambios en varios
    archivos de parches («.patch») como se describe en Sección 5.25,
    “Archivos patches/*”. Puedes seguir los cambios realizados por
    cada archivo debian/patches/* utilizando la orden interdiff.

7.8. La orden mc

    Algunas de las operaciones de comprobación del paquete descritas
    puede realizarse de forma muy intuitiva si empleamos un gestor de
    ficheros como mc(1), que permite visionar tanto el contenido del
    paquete *.deb, como el de los ficheros *.udeb, *.debian.tar.gz,
    *.diff.gz, *.orig.tar.gz.

    Vigila que no haya ficheros innecesarios extra o de tamaño cero,
    tanto en el binario como en el paquete fuente. A veces, hay cosas
    que no se limpiaron adecuadamente, debes ajustar tu fichero rules
    para arreglar esto.


---------------------------------------------------------------------

    ^[75] No es necesario añadir la opción -i -I --show-overrides a
    la orden lintian si la has incluido en la configuración en /etc/
    devscripts.conf o ~/.devscripts según se explicó en Sección 6.3,
    “La orden debuild” .

Capítulo 8. Actualizar el paquete

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Después del lanzamiento del paquete, es posible que debas
    actualizarlo pronto.

8.1. Nueva revisión Debian del paquete

    Supongamos que se ha creado un informe de fallo en tu paquete con
    el número #654321, y que describe un problema que puedes
    solucionar. Para construir una nueva revisión del paquete,
    necesitas:

      * Si debes aplicar una modificación nueva, ejecuta:

          + dquilt new nombre_modificación.patch para establecer el
            nombre de la modificación;

          + dquilt add archivo_a_modificar para establecer el fichero
            al cual se aplicará la modificación.

          + Corregir el problema en el archivo original.

          + dquilt refresh para guardar los cambios realizados en el
            archivo del parche nombre_modificación.patch.

          + dquilt header -e para añadir la descripción (breve) del
            cambio realizado;

      * Si debes actualizar una modificación ya existente, ejecuta:

          + dquilt pop nombre_modificación.patch para deshacer el
            parche nombre_modificación.patch que debes actualizar
            (puesto que se habrá ejecutado y se supone que es
            necesario modificarlo).

          + Corregir el problema existente en la versión incorrecta
            del archivo de parche nombre_modificación.patch.

          + dquilt refresh para actualizar nombre_modificación.patch.

          + dquilt header -e para actualizar la descripción en la
            cabecera del archivo del parche.

          + while dquilt push; do dquilt refresh; done para aplicar
            todos los parches eliminando cosas innecesarias;

      * Añadir la información de la revisión en el inicio del archivo
        changelog (del directorio «Debian»), por ejemplo ejecutando
        dch -i o explícitamente indicando el número de versión y
        revisión ejecutando dch -v versión-revisión, y a continuación
        detallar los cambios realizados utilizando un editor ^[76].

      * Incluye la descripción (breve) del error y la solución,
        seguida de la referencia de la notificación del error con
        (Closes: #654321). De esta manera, el informe de error sera
        «cerrado» automáticamente por el sistema de mantenimiento del
        repositorio Debian cuando el paquete sea aceptado en el
        repositorio.

      * Deberás repetir los pasos anteriores para cada una de las
        modificaciones realizadas en la actualización del paquete, a
        la par que actualizas el fichero changelog de Debian mediante
        dch.

      * Repite lo que hiciste en Sección 6.1, “(Re)construcción
        completa” y Capítulo 7, Comprobación del paquete en busca de
        fallos.

      * Una vez que estes satisfecho, cambia el nombre de la
        distribución en el archivo changelog de UNRELEASED a unstable
        (o bien experimental).^[77]

      * Upload the package as in Capítulo 9, Enviar el paquete. The
        difference is that this time, the original source archive
        won't be included, as it hasn't been changed and it already
        exists in the Debian archive.

    One tricky case can occur when you make a local package, to
    experiment with the packaging before uploading the normal version
    to the official archive, e.g., 1.0.1-1. For smoother upgrades, it
    is a good idea to create a changelog entry with a version string
    such as 1.0.1-1~rc1. You may unclutter changelog by consolidating
    such local change entries into a single entry for the official
    package. See Sección 2.6, “Nombre del paquete y versión” for the
    order of version strings.

   

8.2. Inspección de una nueva versión del autor

    When preparing packages of a new upstream release for the Debian
    archive, you must check the new upstream release first.

    Empieza por leer los archivos changelog, NEWS y cualquier otra
    documentación donde el autor original describa los cambios de la
    nueva versión.

    Puedes comprobar los cambios entre las fuentes originales de la
    nueva versión y de la anterior para detectar cualquier cambio
    sospechoso de producir errores ejecutando:

    $ diff -urN nombre_archivo-versión_anterior nombre_archivo-nueva_versión

    Las modificaciones realizadas en los archivos generados por
    «Autotools» (missing, aclocal.m4, config.guess, config.h.in,
    config.sub, configure, depcomp, install-sh, ltmain.sh y
    Makefile.in) puedes ignorarlas. Puedes eliminarlos antes de
    ejecutar diff en las fuentes para inspeccionarlas.

8.3. Nueva versión del programa fuente

    Si el paquete nombre_del_paquete que examinas está correctamente
    empaquetado utilizando los nuevos formatos 3.0 (native) o 3.0
    (quilt) para empaquetar una nueva versión del autor es esencial
    copiar el directorio debian de la versión anterior a la nueva,
    para a continuación, realizar las adaptaciones necesarias. Puedes
    copiar el directorio debian de la versión anterior a la nueva
    versión ejecutando tar xvzf /ruta/a/nombre_del_paquete_
    versión_anterior.debian.tar.gz desde el directorio de las fuentes
    de la nueva versión ^[78]. A continuación deberás realizar
    algunos tareas obvias:

      * Comprimir las fuentes originales en el archivo
        nombre_del_paquete_nueva_versión.orig.tar.gz.

      * Actualizar el archivo changelog Debian ejecutando dch -v
        nueva_versión-1 .

          + Añade una nueva linea con el texto «New upstream release»
            para indicar que se trata de una nueva versión de las
            fuentes originales.

          + Describe sucintamente los cambios realizados en las
            fuentes originales por el autor que solucionan errores
            informados y cerrar los informes añadiendo Closes: #
            numero_del_error.

          + Describe sucintamente los cambios de la nueva versión del
            desarrollador que solucionan errores previamente
            reportados y cierra dichos errores añadiendo Closes: #
            número_del_error.

      * while dquilt push; do dquilt refresh; done para aplicar todos
        los parches eliminando cosas innecesarias;

    Si las modificaciones no se ejecutan correctamente, inspecciona
    la situación (mira la información de los archivos .rej) como se
    muestra a continuación.

      * Si uno de los parches aplicados está integrado en las fuentes
        originales,

          + ejecuta dquilt delete para eliminarlo.

      * Si uno de los parches entra en conflicto con los cambios
        realizados por el autor en las fuentes originales,

          + ejecuta dquilt push -f para aplicar los parches de la
            versión anterior para forzar los rechazos (tendrás la
            información de los rechazos en los archivos rechazo.rej).

          + Edita los archivos rechazo.rej manualmente para saber el
            efecto que se pretende con rechazo.rej.

          + Ejecuta dquilt refresh para actualizar el parche.

      * Continua hasta la ejecución de while dquilt push; do dquilt
        refresh; done.

    Puedes automatizar este proceso utilizando la orden uupdate(1)
    como sigue:

    $ apt-get source nombre_del_paquete
    ...
    dpkg-source: info: extracting nombre_del_paquete in nombre_del_paquete-versión_anterior
    dpkg-source: info: unpacking nombre_del_paquete_versión_anterior.orig.tar.gz
    dpkg-source: info: applying nombre_del_paquete_versión_anterior-1.debian.tar.gz
    $ ls -F
    nombre_del_paquete-versión_anterior/
    nombre_del_paquete_versión_anterior-1.debian.tar.gz
    nombre_del_paquete_versión_anterior-1.dsc
    nombre_del_paquete_versión_anterior.orig.tar.gz
    $ wget http://ejemplo.org/nombre_del_paquete/nombre_del_paquete-nueva_versión.tar.gz
    $ cd nombre_del_paquete-versión_anterior
    $ uupdate -v nueva_versión ../nombre_del_paquete-nueva_versión.tar.gz
    $ cd ../nombre_del_paquete-nueva_versión
    $ while dquilt push; do dquilt refresh; done
    $ dch
    ... documenta las modificaciones realizadas

    Si has configurado el archivo «debian/watch» como se ha descrito
    en Sección 5.21, “Archivo watch” ,puedes saltarte la orden wget.
    Simplemente, ejecuta uscan(1) en el directorio nombre_del_paquete
    -antigua_versión en lugar de la orden uupdate. Así, se buscará 
    automáticamente el archivo de las fuentes, se descargará en tu
    ordenador y se ejecutará la orden uupdate ^[79].

    Puedes liberar la nueva versión del paquete repitiendo lo
    expuesto en Sección 6.1, “(Re)construcción completa” ,
    Capítulo 7, Comprobación del paquete en busca de fallos y
    Capítulo 9, Enviar el paquete .

8.4. Actualizar el formato del paquete

    Para actualizar un paquete no es necesario actualizar el formato
    del paquete. Aún así, puedes aprovechar completamente la
    funcionalidad de debhelper y del formato 3.0 haciendo lo
    siguiente ^[80]:

      * Si necesitas de nuevo algunos de los archivos de plantilla
        eliminados, puedes regenerarlos ejecutando otra vez dh_make
        con la opción --addmissing en el directorio de las fuentes. A
        continuación modifícalos correctamente.

      * Si el paquete no está actualizado para utilizar la nueva
        sintaxis de la versión 7+ de la orden dh de debhelper en el
        archivo debian/rules, actualízalo para usar dh. También
        deberás actualizar debian/control.

      * Si deseas actualizar el archivo rules construido por el
        mecanismo de inclusión Makefile del sistema de compilación
        Debian (cdbs) a la nueva sintaxis dh, lee el siguiente
        documento para comprender las variables de configuración
        DEB_*.

          + copia local de /usr/share/doc/cdbs/cdbs-doc.pdf.gz

          + The Common Debian Build System (CDBS), FOSDEM 2009

      * Si estás trabajando con un paquete construido con el formato
        1.0 sin el archivo nombre_del_paquete.diff.gz, puedes
        actualizarlo a la nueva versión 3.0 (native) añadiendo el
        archivo debian/source/format con la linea 3.0 (native). Copia
        los otros archivos del directorio debian/*.

      * Si estás trabajando con un paquete construido con el formato
        1.0 con el archivo nombre_del_paquete.diff.gz, puedes
        actualizarlo a la nueva versión 3.0 (native) añadiendo el
        archivo debian/source/format con la linea 3.0 (native). Copia
        los otros archivos del directorio debian/*. Importa el
        archivo nombre_del_paquete.diff generado por la orden
        filterdiff -z -x '*/debian/*' nombre_del_paquete.diff.gz >
        nombre_del_paquete.diff al sistema quilt ^[81].

      * Si el paquete se ha construido utilizando un sistema de
        parches distinto como dpatch, dbs o cdbs utilizando las
        opciones -p0, -p1 o -p2, puedes convertirlo al formato quilt
        utilizando el guión deb3 explicado en http://bugs.debian.org/
        581186.

      * Si el paquete se ha construido ejecutando la orden dh con la
        opción --with quilt o bien con dh_quilt_patch y 
        dh_quilt_unpatch, elimina todo esto y utiliza el nuevo
        formato fuente 3.0 (quilt).

    Consulte DEP - Debian Enhancement Proposals y adoptar las
    propuestas ACEPTADAS.

    Repasa la sección Sección 8.3, “Nueva versión del programa
    fuente” por si debes repetir algunos de los pasos indicados en
    ella.

8.5. Conversión a UTF-8

    Si los documentos originales utilizan una codificación antigua,
    es una buen práctica actualizarlos a UTF-8.

      * Utiliza iconv(1) para hacer conversiones de codificación en
        ficheros de texto sin formato.

        iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt

      * Utiliza w3m(1) para conversiones desde ficheros HTML a ficheros
        de texto sin formato con codificación UTF-8. Al hacerlo, el
        sistema debe estar configurado para usar la codificación UTF-8.

        LC_ALL=C.UTF-8 w3m -o display_charset=UTF-8 \
                -cols 70 -dump -no-graph -T text/html \
                < nombre_del_archivo_a_modificar.html > nombre_del_archivo_modificado.txt

8.6. Recordatorio para actualizar paquetes

    Here are a few reminders for updating packages:

      * Conserva las entradas anteriores del archivo changelog (suena
        a obviedad, pero se han dado casos de ejecutar dch en lugar
        de dch -i).

      * Los cambios en la construcción del paquete Debian deben ser
        reconsiderados; elimina las modificaciones anteriores (sea lo
        que sea) y recuerda de añadir todo lo necesario, a no ser que
        haya una buena razón para no hacerlo.

      * Si se ha realizado alguna modificación en la compilación (te
        enterarás al inspeccionar los cambios en las fuentes
        originales) puede que sea necesario actualizar el archivo
        debian/rules y las dependencias de compilación en el archivo
        debian/control.

      * Debes comprobar si hay alguna comunicación de parches del
        paquete en el sistema de gestión de errores (puede darse el
        caso que algún usuario envíe un parche ya construido y que te
        sea de utilidad) en Debian Bug Tracking System (BTS).

      * Comprueba el contenido del archivo .changes para asegurarte
        que envías el paquete a la distribución correcta, que los
        informes de errores que se cierran con la nueva versión del
        paquete están listados en el campo Closes del archivo, que el
        contenido de los campos Maintainer y Changed-By son
        correctos, que has firmado el archivo con tu clave GPG, etc.


---------------------------------------------------------------------

    ^[76] Para escribir la fecha y hora en el formato requerido,
    debes utilizar LANG=C date -R.

    ^[77] Si utiliza la orden dch -r para realizar este último
    cambio, asegúrese que guarda el archivo changelog explícitamente
    con el editor.

    ^[78] Si el paquete nombre_del_paquete está construido con el
    anterior formato 1.0, esto se puede hacer ejecutando zcat /ruta/a
    /nombre_del_paquete_numero_de_versión_anterior.diff.gz|patch -p1
    en la nueva versión de las fuentes.

    ^[79] Si la orden uscan descargar las fuentes pero no ejecuta la
    orden uupdate, debes corregir el archivo debian/watch añadiendo
    debian uupdate al final de la URL del archivo.

    ^[80] Si quien patrocina tu paquete u otros desarrolladores hacen
    objeciones a la actualización del formato del paquete, no vale la
    pena empeñarse en argumentar a favor. Hay otras cosas más
    importantes que atender.

    ^[81] Puedes fragmentar el archivo nombre_del_paquete.diff en
    varios archivos de parches utilizando la orden splitdiff.

Capítulo 9. Enviar el paquete

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Debian now requires source-only uploads for normal upload. So
    this page is outdated.

    Ahora que has probado tu nuevo paquete en profundidad, podrás
    transferirlo a un archivo público para compartirlo.

9.1. Enviar al repositorio de Debian

    Cuando seas desarrollador oficial Debian ^[82], podrás transferir
    el paquete al repositorio de Debian ^[83]. Puedes hacer esto
    manualmente, pero es más fácil hacerlo con las herramientas
    automáticas ya disponibles como dupload(1) o dput(1). A
    continuación describiremos cómo hacerlo con dupload ^[84].

    En primer lugar, debes generar un fichero de configuración de 
    dupload. Puedes hacerlo editando el fichero general del sistema /
    etc/dupload.conf, o generando tu propio fichero ~/.dupload.conf
    con lo que tu quieras cambiar.

    Consulta el manual de dupload.conf(5) para saber el significado
    de cada opción.

    La opción $default_host es la más problemática; determina cuál de
    las colas de envíos se usará por omisión. «anonymous-ftp-master»
    es la primaria, pero es posible que quieras usar otra más rápida
    ^[85].

    Si tienes conexión a Internet, puedes subir el paquete de la
    siguiente manera:

      dupload gentoo_0.9.12-1_i386.changes

    dupload comprueba que las sumas MD5/SHA1/SHA256 de los archivos
    transferidos coinciden con las listadas en el fichero .changes,
    si no coinciden te avisará para que reconstruyas el paquete como
    se describe en Sección 6.1, “(Re)construcción completa” para
    poder enviarlo correctamente.

    Si encuentras algún problema con la subida del paquete a ftp://
    ftp.upload.debian.org/pub/UploadQueue/, puedes arreglarlo
    subiendo manualmente un fichero *.commands firmado con GPG con la
    orden ftp ^[86]. Por ejemplo, utiliza hello.commands:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    Uploader: Foo Bar <Foo.Bar@example.org>
    Commands:
     rm hello_1.0-1_i386.deb
     mv hello_1.0-1.dsx hello_1.0-1.dsc
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    [...]
    -----END PGP SIGNATURE-----

9.2. Incluir orig.tar.gz para la transferencia del paquete al
repositorio.

    Cuando se envía por primera vez al archivo, se debe incluir el
    archivo orig.tar.gz con las fuentes originales. Si el número de
    revisión Debian del paquete no es ni 1 ni 0, debes ejecutar la
    orden dpkg-buildpackage con la opción -sa. Por otra parte, es
    posible excluir la inclusión del archivo fuente original
    orig.tar.gz con la opción -sd.

    Para la orden dpkg-buildpackage:

    $ dpkg-buildpackage -sa

    Para la orden debuild:

    $ debuild -sa

    Para la orden pdebuild:

    $ pdebuild --debbuildopts -sa

    Por otra parte, con la opción -sd se evita la inclusión del
    archivo orig.tar.gz con las fuentes originales.

9.3. Envíos discontinuados

    If you created multiple entries in debian/changelog by skipping
    uploads, you must create a proper *_.changes file that includes
    all changes since the last upload. This can be done by specifying
    the dpkg-buildpackage option -v with the version, e.g., 1.2.

    Para la orden dpkg-buildpackage:

    $ dpkg-buildpackage -v1.2

    Para la orden debuild:

    $ debuild -v1.2

    Para la orden pdebuild:

    $ pdebuild --debbuildopts "-v1.2"


---------------------------------------------------------------------

    ^[82] Consulta Sección 1.1, “Dinamismo social en Debian”.

    ^[83] Hay archivos públicamente accesibles, como http://
    mentors.debian.net/ que funcionan de forma similar al archivo
    Debian y facilitan un sistema de transferencia de paquetes para
    personas que no son desarrolladores oficiales («DD»). Tu puedes
    construirte un archivo personal utilizando las herramientas
    listadas en http://wiki.debian.org/HowToSetupADebianRepository.
    Así, esta sección también es útil si no eres «DD».

    ^[84] Consulta Sección 1.1, “Dinamismo social en Debian”.

    ^[85] See Debian Developer's Reference 5.6, "Uploading a
    package".

    ^[86] Consulta ftp://ftp.upload.debian.org/pub/UploadQueue/
    README. Como alternativa, puedes usar la orden dcut del paquete
    dput.

Apéndice A. Técnicas avanzadas

    The rewrite of this tutorial document with updated contents and
    more practical examples is available as Guide for Debian
    Maintainers. Please use this new tutorial as the primary tutorial
    document.

    Here are some hints and pointers for advanced packaging topics
    that you are most likely to deal with. You are strongly advised
    to read all the references suggested here.

    Puede ser necesario editar manualmente los ficheros de las
    plantillas generadas con la orden dh_make para abordar los temas
    tratados en este capítulo. La nueva orden debmake maneja mejor
    estos aspectos de la construcción de paquetes.

A.1. Bibliotecas compartidas

    Antes de empaquetar bibliotecas compartidas, debes leer
    atentamente la siguientes referencias básicas:

      * Debian Policy Manual, 8 "Shared libraries"

      * Debian Policy Manual, 9.1.1 "File System Structure"

      * Debian Policy Manual, 10.2 "Libraries"

    Éstos son algunos consejos básicos para empezar:

      * Las bibliotecas compartidas son archivos objeto en formato
        ELF que contienen código compilado.

      * Las bibliotecas compartidas se distribuyen como ficheros *.so
        (no como ficheros *.a o *.la).

      * Las bibliotecas compartidas se utilizan principalmente para
        compartir código común entre varios ejecutables con la orden 
        ld.

      * Las bibliotecas compartidas se utilizan, a veces, para
        proveer varios complementos («plugins») a un ejecutable
        mediante el procedimiento dlopen.

      * Shared libraries export symbols, which represent compiled
        objects such as variables, functions, and classes; and enable
        access to them from the linked executables.

      * El SONAME (el nombre lógico) de la biblioteca compartida lib
        nombre_biblioteca.so.1: objdump -p libnombre_biblioteca.so.1
        | grep SONAME ^[87]

      * El «SONAME» (el nombre lógico) de una biblioteca compartida
        generalmente coincide con el nombre del archivo de biblioteca
        (pero no siempre).
   
      * El «SONAME» (el nombre lógico) de las bibliotecas compartidas
        enlazadas a /usr/bin/foo: objdump -p /usr/bin/foo | grep
        NEEDED ^[88]

      * libfoo1: el paquete de biblioteca de la biblioteca compartida
        libfoo.so.1 con la versión ABI del nombre lógico («SONAME») 1
        .^[89]

      * Los guiones de desarrollador de un paquete de biblioteca
        deben ejecutar ldconfig cuando sea necesario para generar los
        enlaces simbólicos para el «SONAME» (el nombre lógico).^[90]

      * libfoo1-dbg: the debugging symbols package that contains the
        debugging symbols for the shared library package libfoo1.

      * libfoo-dev: the development package that contains the header
        files etc. for the shared library libfoo.so.1.^[91]

      * Debian packages should not contain *.la Libtool archive files
        in general.^[92]

      * Debian packages should not use RPATH in general.^[93]

      * Aunque está un poco anticuado y es sólo una referencia
        secundaria, Debian Library Packaging Guide aún puede ser
        útil.

A.2. Gestionando debian/package.symbols

    When you package a shared library, you should create a debian/
    package.symbols file to manage the minimal version associated
    with each symbol for backward-compatible ABI changes under the
    same SONAME of the library for the same shared library package
    name.^[94] You should read the following primary references in
    detail:

      * Debian Policy Manual, 8.6.3 "The symbols system"^[95]

      * dh_makeshlibs(1)

      * dpkg-gensymbols(1)

      * dpkg-shlibdeps(1)

      * deb-symbols(5)

    Here is a rough example of how to create the libfoo1 package from
    the upstream version 1.3 with the proper debian/libfoo1.symbols
    file:

      * Preparar el esqueleto de directorios fuente Debian utilizando el
        fichero con las fuentes libfoo-1.3.tar.gz.

          + Si es la primera versión del paquete libfoo1, genera un
            fichero debian/libfoo1.symbols en blanco.

          + Si la versión anterior del autor (la 1.2) fue empaquetada en
            el paquete libfoo1 con el fichero debian/libfoo1.symbols
            adecuado en el paquete fuente, utilízalo otra vez.

          + If the previous upstream version 1.2 was not packaged with
            debian/libfoo1.symbols, create it as the symbols file from
            all available binary packages of the same shared library
            package name containing the same SONAME of the library, for
            example, versions 1.1-1 and 1.2-1. ^[96]

            $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1
            $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1
            $ : > symbols
            $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols
            $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols

      * Make trial builds of the source tree with tools such as debuild
        and pdebuild. (If this fails due to missing symbols etc., there
        were some backward-incompatible ABI changes that require you to
        bump the shared library package name to something like libfoo1a
        and you should start over again.)

        $ cd libfoo-1.3
        $ debuild
        ...
        dpkg-gensymbols: advertencia: hay símbolos nuevos en el fichero de símbolos: ...
         mire las diferencias a continuación
        --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64)
        +++ dpkg-gensymbolsFE5gzx        2012-11-11 02:24:53.609667389 +0900
        @@ -127,6 +127,7 @@
          foo_get_name@Base 1.1
          foo_get_longname@Base 1.2
          foo_get_type@Base 1.1
        + foo_get_longtype@Base 1.3-1
          foo_get_symbol@Base 1.1
          foo_get_rank@Base 1.1
          foo_new@Base 1.1
        ...

      * If you see the diff printed by the dpkg-gensymbols as above,
        extract the proper updated symbols file from the generated binary
        package of the shared library. ^[97]

        $ cd ..
        $ dpkg-deb -R  libfoo1_1.3_amd64.deb libfoo1-tmp
        $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \
                >libfoo-1.3/debian/libfoo1.symbols

      * Compilar paquetes para publicarlos con herramientas como debuild
        y pdebuild.

        $ cd libfoo-1.3
        $ debuild -- clean
        $ debuild
        ...

    Además de los ejemplos anteriores, también debes comprobar la
    compatibilidad ABI con más atención y actualizar manualmente las
    versiones de los símbolos (si es necesario). ^[98]

    Aunque es sólo una referencia secundaria, Debian wiki
    UsingSymbolsFiles y sus enlaces a otras páginas web puede ser
    útil.

A.3. Varias arquitecturas

    La función de varias arquitecturas introducida en Debian «wheezy»
    integra la instalación en más de una arquitectura de los paquetes
    binarios (en particular i386<->amd64, pero también con otras
    combinaciones) en dpkg y apt. Se recomienda leer atentamente las
    siguientes referencias:

      * Ubuntu wiki MultiarchSpec (desarrollador original)
   
      * Debian wiki Multiarch/Implementation (Debian)

    Se utilizan tripletes del tipo i386-linux-gnu y x86_64-linux-gnu
    para el directorio de instalación de bibliotecas compartidas. El
    triplete de trabajo se establece dinámicamente al valor $
    (DEB_HOST_MULTIARCH) por dpkg-architecture(1) para cada
    compilación. Por ejemplo, el directorio de instalación de
    bibliotecas para varias arquitecturas se cambia como sigue:^[99]

    
    +---------------------------------------------------------------+
    | Directorio  |       directorio       |       directorio       |
    |   antiguo   |multi-arquitectura i386 |multi-arquitectura amd64|
    |-------------+------------------------+------------------------|
    |/lib/        |/lib/i386-linux-gnu/    |/lib/x86_64-linux-gnu/  |
    |-------------+------------------------+------------------------|
    |/usr/lib/    |/usr/lib/i386-linux-gnu/|/usr/lib/               |
    |             |                        |x86_64-linux-gnu/       |
    +---------------------------------------------------------------+

    Here are some typical multiarch package split scenario examples
    for the following:

      * el código fuente de la biblioteca libfoo-1.tar.gz

      * el código fuente de una orden bar-1.tar.gz escrito en un
        lenguaje compilado

      * el código fuente de una orden baz-1.tar.gz escrito en un
        lenguaje interpretado

    
    +---------------------------------------------------------------+
    |  Paquete   |Arquitectura:|Multi-arquitectura:| Contenido del  |
    |            |             |                   |    paquete     |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |la biblioteca   |
    |libfoo1     |any          |same               |compartida,     |
    |            |             |                   |coinstalable    |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los símbolos de |
    |            |             |                   |depuración de la|
    |libfoo1-dbg |any          |same               |biblioteca      |
    |            |             |                   |compartida,     |
    |            |             |                   |coinstalable    |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los ficheros de |
    |            |             |                   |cabeceras y     |
    |libfoo-dev  |any          |same               |otros de una    |
    |            |             |                   |biblioteca      |
    |            |             |                   |compartida,     |
    |            |             |                   |coinstalable    |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los programas de|
    |            |             |                   |soporte en      |
    |libfoo-tools|any          |foreign            |tiempo de       |
    |            |             |                   |ejecución no son|
    |            |             |                   |co-instalables. |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los ficheros de |
    |libfoo-doc  |all          |foreign            |documentación de|
    |            |             |                   |la biblioteca   |
    |            |             |                   |compartida      |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los ficheros    |
    |bar         |any          |foreign            |compilados del  |
    |            |             |                   |programa, no son|
    |            |             |                   |coinstalables   |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los ficheros de |
    |bar-doc     |all          |foreign            |documentación   |
    |            |             |                   |del programa    |
    |------------+-------------+-------------------+----------------|
    |            |             |                   |los ficheros de |
    |baz         |all          |foreign            |programa        |
    |            |             |                   |interpretados   |
    +---------------------------------------------------------------+

    Hay que tener en cuenta que el paquete de desarrollo debe
    contener un enlace simbólico a la biblioteca compartida asociada 
    sin el número de versión. P. ej.: /usr/lib/x86_64-linux-gnu/
    libfoo.so -> libfoo.so.1

A.4. Construcción de un paquete de biblioteca compartida

    You can build a Debian library package enabling multiarch support
    using dh(1) as follows:

      * Actualizar debian/control.

          + Add Build-Depends: debhelper (>=10) for the source package
            section.

          + Añadir Pre-Depends: ${misc:Pre-Depends} por cada paquete
            binario de biblioteca compartida.

          + Añadir el campo Multi-Arch: en cada sección de paquete
            binario.

      * Set debian/compat to "10".

      * Cambiar el directorio habitual /usr/lib/ por el directorio
        multi-arquitectura /usr/lib/$(DEB_HOST_MULTIARCH)/ para todos los
        guiones de empaquetado.

          + Call DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture
            -qDEB_HOST_MULTIARCH) in debian/rules to set the
            DEB_HOST_MULTIARCH variable first.

          + Reemplazar /usr/lib/ por /usr/lib/$(DEB_HOST_MULTIARCH)/ en
            debian/rules.

          + If ./configure is used in part of the
            override_dh_auto_configure target in debian/rules, make sure
            to replace it with dh_auto_configure -- . ^[100]

          + Cambiar todas referencias a /usr/lib/ por /usr/lib/*/ en los
            ficheros debian/nombre_del_paquete.install

          + Generate files like debian/foo.links from debian/foo.links.in
            dynamically by adding a script to the
            override_dh_auto_configure target in debian/rules.

            override_dh_auto_configure:
                    dh_auto_configure
                    sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
                            debian/nombre_del_paquete.links.in > debian/nombre_del_paquete.links

    Debes comprobar que el paquete de biblioteca compartida solo
    contiene los ficheros esperados y que el paquete «-dev» sigue
    funcionando correctamente.

    All files installed simultaneously as the multiarch package to
    the same file path should have exactly the same file content. You
    must be careful of differences generated by the data byte order
    and by the compression algorithm.

A.5. Paquete nativo Debian

    Si un paquete se mantiene exclusivamente para Debian o para uso
    local, su paquete fuente puede contener todos los ficheros debian
    /*. Hay dos maneras para empaquetarlos.

    You can make the upstream tarball by excluding the debian/* files
    and package it as a non-native Debian package as in Sección 2.1,
    “Plan de trabajo para la construcción de paquetes Debian”. This
    is the normal way, which some people encourage using.

    La alternativa es el esquema de trabajo para paquetes nativos
    Debian.

      * Generaremos un paquete fuente Debian en el formato 3.0
        (native), utilizando un archivo comprimido en formato «tar»
        que incluirá todos los archivos.

          + nombre_del_paquete_versión.tar.gz
          + nombre_del_paquete_versión.dsc
      * Construiremos un paquete binario Debian del paquete de
        fuentes nativo Debian.

          + nombre_del_paquete_versión_arquitectura.deb

    For example, if you have source files in ~/mypackage-1.0 without
    the debian/* files, you can create a native Debian package by
    issuing the dh_make command as follows:

    $ cd ~/mi_paquete-1.0
    $ dh_make --native

    Then the debian directory and its contents are created just like
    in Sección 2.8, “Paquete no nativo Debian inicial”. This does not
    create a tarball, since this is a native Debian package. But that
    is the only difference. The rest of the packaging activities are
    practically the same.

    Después de la ejecución de la orden dpkg-buildpackage,
    encontrarás los siguientes ficheros en el directorio superior:

      * mi_paquete_1.0.tar.gz

        Este es el archivo del código fuente generado a partir del
        directorio mi_paquete-1.0 por la orden dpkg-source (su sufijo
        no es orig.tar.gz.).

      * mi_paquete_1.0.dsc

        This is a summary of the contents of the source code, as in
        the non-native Debian package. (There is no Debian revision.)
   
      * mi_paquete_1.0_i386.deb

        This is your completed binary package, as in the non-native
        Debian package. (There is no Debian revision.)

      * mi_paquete_1.0_i386.changes

        Este archivo describe todos los cambios realizados en el
        versión actual del paquete en el caso de los paquetes Debian
        no nativos (no tiene código de revisión Debian).


---------------------------------------------------------------------

    ^[87] Como alternativa: readelf -d libnombre_biblioteca.so.1 |
    grep SONAME

    ^[88] Como alternativa: readelf -d libfoo.so.1 | grep NEEDED

    ^[89] Véase Debian Policy Manual, 8.1 "Run-time shared
    libraries".

    ^[90] Véase Debian Policy Manual, 8.1.1 "ldconfig".

    ^[91] Consulta Debian Policy Manual, 8.3 "Static libraries" y
    Debian Policy Manual, 8.4 "Development files".

    ^[92] Consulta Debian wiki ReleaseGoals/LAFileRemoval.

    ^[93] Consulta Debian wiki RpathIssue.

    ^[94] Los cambios ABI incompatibles con versiones anteriores,
    normalmente requieren actualizar el «SONAME» (el nombre lógico)
    de la biblioteca y el de la biblioteca compartida a otros nuevos.

    ^[95] Para bibliotecas C++ y otros casos en los que el
    seguimiento individual de símbolos es difícil, es mejor consultar
    Debian Policy Manual, 8.6.4 "The shlibs system".

    ^[96] Las versiones previas de los paquetes Debian están
    disponibles en http://snapshot.debian.org/. La revisión Debian
    del paquete sigue a la versión para facilitar mantenimiento de
    versiones anteriores («backport») del paquete: 1.1 <<
    1.1-1~bpo70+1 << 1.1-1 y 1.2 << 1.2-1~bpo70+1 << 1.2-1

    ^[97] La revisión de Debian se deriva de la versión para hacer
    más fácil el mantenimiento de versiones anteriores («backport»)
    del paquete: 1.3 << 1.3-1~bpo70+1 << 1.3-1

    ^[98] Véase Debian Policy Manual, 8.6.2 "Shared library ABI
    changes".

    ^[99] Old special purpose library paths such as /lib32/ and /
    lib64/ are not used anymore.

    ^[100] Como alternativa, puedes añadir los argumentos --libdir=\
    $${prefix}/lib/$(DEB_HOST_MULTIARCH) y --libexecdir=\$${prefix}/
    lib/$(DEB_HOST_MULTIARCH) en ./configure. Fíjate que --libexecdir
    especifica el directorio predeterminado para la instalación de
    programas ejecutables que son ejecutados por otros programas en
    lugar de por los usuarios. El valor predeterminado por
    «Autotools» es /usr/libexec/ pero en Debian es /usr/lib/.

