Tabla de contenidos
README.Debian
(LÉEME.debian)
compat
conffiles
nombre_del_paquete
.cron.*
dirs
nombre_del_paquete
.doc-base
docs
emacsen-*
nombre_del_paquete
.examples
nombre_del_paquete
.init
y
nombre_del_paquete
.default
install
nombre_del_paquete
.info
nombre_del_paquete
.links
{nombre_del_paquete
.source/}
lintian-overrides
manpage.*
nombre_del_paquete
.manpages
menu
NEWS
{pre,post}{inst,rm}
nombre_del_paquete
.symbols
TODO
watch
source/format
source/local-options
source/options
patches/*
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.
La orden dh_make construye varios archivos de
configuración a modo de plantillas y los ubica en el directorio
debian
. Algunos de ellos tienen el sufijo
.ex
(de «example») en el nombre. Otros tienen como
prefijo del nombre el nombre del paquete en la forma
. Mira el
contenido de todos ellos. [54]
nombre_del_paquete
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.
elimina los sufijos .ex
o .EX
de los
archivos de plantilla que lo tengan.
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
tales
como nombre_del_paquete
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
, etc.
paquete-2
.install
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).
El archivo compat
define el nivel de compatibilidad de
debhelper
. Actualmente,
establecerás la compatibilidad a la versión 9 de debhelper
como se indica a continuación.
$ echo 9 > debian/compat
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. [55] 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.19, “Archivos {pre,post}{inst,rm}
” .
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:
- instalados como
nombre_del_paquete
.cron.hourly/etc/cron.hourly/
:
se ejecutan cada hora.
nombre_del_paquete
- instalados como
nombre_del_paquete
.cron.daily/etc/cron.daily/
:
se ejecutan cada día, habitualmente por la mañana temprano.
nombre_del_paquete
- instalados como
nombre_del_paquete
.cron.weekly/etc/cron.weekly/
:
se ejecutan cada semana, habitualmente en la mañana del domingo.
nombre_del_paquete
- instalados como
nombre_del_paquete
.cron.hourly/etc/cron.hourly/
:
se ejecutan cada hora.
nombre_del_paquete
-
instalados como
nombre_del_paquete
.cron.d/etc/cron.d/
: para
cualquier otro período de tiempo.
package
Para los archivos mencionados, su formato es el de guiones «shell». La
única excepción son los archivos
que deben ajustarse al formato descrito en crontab(5).
nombre_del_paquete
.cron.d
No es necesario determinar un archivo cron.*
para
configurar la rotación de registros, para hacer eso consulta dh_installlogrotate(1) y logrotate(8).
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
.
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” .
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
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.
La orden dh_installexamples(1) instala los archivos y directorios listados en este archivo como archivos de ejemplos.
Si tu paquete es un demonio que necesita ejecutarse en el arranque del sistema, obviamente has desatendido mi recomendación inicial, ¿o no? :-)
El archivo
se
instala como un guión en
nombre_del_paquete
.init/etc/init.d/
.
Se trata de una plantilla genérica construida por la orden
dh_make como nombre_del_paquete
init.d.ex
. Deberás
renombrarlo y hacerle muchos cambios para asegurarte que cumpla con las
cabeceras del estándar base de Linux (Linux Standard
Base, LSB). La orden dh_installinit(1) lo instalará en el directorio temporal.
El archivo
se instalará en el directorio
nombre_del_paquete
.default/etc/default/
.
Este archivo establece los valores predeterminados que utiliza el
guión init. En la mayoría de casos, el archivo
nombre_del_paquete
,
se utiliza para desactivar la ejecución del demonio, estableciendo algunos
indicadores predeterminados o tiempos de espera. Las características
configurables establecidas en tu guión
init deben incluirse en este archivo predeterminado, y no en el
propio guión.
nombre_del_paquete
.default
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/
.
En cualquier caso deberás construir los enlaces simbólicos
nombre_del_paquete
.initrc*
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.
Si hay archivos que deben ser instalados por el paquete pero no lo hace
make install
, puedes listar los archivos y sus destinos
en el archivo install
. Se encargará de la instalación
la orden dh_install(1) [56]. Debes asegurarte que no hay un sistema más específico para hacer
esta instalación. Por ejemplo, para la documentación debes utilizar el
archivo docs
, en lugar de este archivo.
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/
no se
instalase, deberías utilizar el archivo archivo_binario
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
,
etc.
nombre_del_paquete-2
.install
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
).
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
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
Si el programa lintian
emite un
informe de diagnóstico erróneo en algún caso en que las normas admitan
excepciones, podrás utilizar los archivos
o nombre_del_paquete
.lintian-overridessource/lintian-overrides
para evitar que se emita el
error. Por favor, lee Lintian User's Manual
(/usr/share/doc/lintian/lintian.html/index.html
) error y procura no abusar de esta
opción (para ocultar errores auténticos).
es para un paquete binario con el nombre nombre_del_paquete
.lintian-overrides
y
es instalado en
nombre_del_paquete
usr/share/lintian/overrides/
por la orden dh_lintian.
nombre_del_paquete
El archivo source/lintian-overrides
es para los
paquetes de fuentes y no se instala.
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.
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 sistema | Funciones proporcionadas por el núcleo |
3 | Llamadas a bibliotecas | Funciones de las bibliotecas del 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 sistema | Programas que sólo suele ejecutar 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 [57].
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
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
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
Los usuarios de X Windows suelen tener un gestor de ventanas con menús que
pueden adaptarse para lanzar programas. Si tienen instalado el paquete
menu
de Debian, se generará un
conjunto de menús para cada programa del sistema para ellos.
Éste es el fichero menu.ex
que
dh_make construye por omisión:
?package(gentoo):needs=X11|text|vc|wm section=Apps/lea-manual-menu\ title=gentoo command=/usr/bin/gentoo
El primer campo tras la coma es needs
(necesidades) y
especifica qué tipo de interfaz necesita el programa. Cambia ésta a una de
las alternativas que se listan, como por ejemplo text
o
X11
..
El siguiente section
, es la sección donde deberían
aparecer la entrada del menú y del sub-menú [58].
El campo title
es el nombre del programa. Puedes
comenzar éste en mayúsculas si así lo prefieres, pero hazlo lo más corto
posible.
Finalmente, el campo command
es la orden que ejecuta el
programa.
Vamos a cambiar el nombre del archivo a menu
y la
entrada del menú por ésta:
?package(gentoo): needs=X11 \ section=Applications/Tools \ title=Gentoo command=gentoo
También puedes añadir otros campos como son longtitle
(título largo), icon
(icono), hints
(pistas), etc. Para más información consulta dh_installmenu(1), menufile(5), update-menus(1) y The Debian Menu
sub-policy.
Los archivos postinst
, preinst
,
postrm
y prerm
[59] 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.
El mantenimiento de paquetes de bibliotecas no es fácil para los
principiantes y se debe evitar. Aún así, si el paquete tiene bibliotecas,
debes tener los ficheros
debian/
.
Consulte Sección A.2, “Gestionando
nombre_del_paquete
.symbolsdebian/
”.
package
.symbols
El formato del archivo watch
se documenta en la página
de manual de uscan(1). El archivo
watch
se usa para configurar el programa
uscan (del paquete devscripts
) que vigila el servidor de donde
obtuviste las fuentes originales. También lo utiliza «Debian External Health Status (DEHS)».
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.
Aunque es posible hacer esto con otros portales, el servicio de descarga de
«SourceForge» en http://sf.net es una excepción.
Cuando el archivo watch
tiene una URL que concuerda con
el patrón Perl ^http://sf\.net/
, el programa
uscan lo substituye por
http://qa.debian.org/watch/sf.php/
y después aplica esta regla. El
servicio de redireccionamiento URL a la dirección http://qa.debian.org/ está diseñado para ofrecer un servicio estable
de redireccionamiento al archivo presente en watch
y
que concuerda con
http://sf.net/
.
Esto resuelve los problemas relacionados con los cambios periódicos en la
dirección URL.
proyecto
/nombre_archivo_tar
-(.+)\.tar\.gz
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).
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 [60]. 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 [61].
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
.
Si deseas gestionar los trabajos de empaquetado en un entorno VCS,
seguramente tendrás una rama (p.ej. upstream
) que sigue
las fuentes originales y otra rama (p.ej. normalmente
master
en Git) para el paquete Debian. Para este último
caso, generalmente tendrás las fuentes originales sin modificar (sin
aplicarles los parches) con los archivos debian/*
para
el empaquetamiento Debian para facilitar la fusión con las nuevas versiones
de las fuentes.
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
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)$"
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
[62].
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 [63].
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
para las
fuentes, cuando ya está construido el paquete, la modificación de un paquete
con formato nombre_parche
.patch3.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]
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.
[55] Véase dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles".
[56] Esto reemplaza la orden obsoleta dh_movefiles(1) que se configuraba con el archivo
files
.
[57] 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.
[58] La lista actual de secciones está en The
Debian Menu sub-policy 2.1 "Preferred menu structure". Se realizó
una reorganización importante del menú en la versión
squeeze
.
[59] 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.
[61] 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.
[62] 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/*
.
[63] 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.