[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ siguiente ]
debian
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», «rules», «changelog», y «copyright» que son necesarios en todos los paquetes.
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 crea para nosotros:
1 Source: gentoo
2 Section: unknown
3 Priority: extra
4 Maintainer: Josip Rodin <joy-mg@debian.org>
5 Build-Depends: debhelper (>= 7.0.50~)
6 Standards-Version: 3.8.4
7 Homepage: <introduce aquí la URL del autor original >
8
9 Package: gentoo
10 Architecture: any
11 Depends: ${shlibs:Depends}, ${misc:Depends}
12 Description: <insertar hasta 60 caracteres de descripción>
13 <inserta una descripción larga, indentada con espacios.>
(He añadido los números de línea)
Las líneas 1 a 6 son la información de control para el paquete fuente.
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.
Vamos a cambiarla para que ponga x11. El prefijo «main/» ya va implícito,
así que podemos omitirlo. Véase Manual
de normas de Debian, 2.4 'Secciones' y Lista de secciones en
«sid» para más información.
La línea 3 describe cómo de importante es para el usuario la instalación de
este paquete. Podrás consultar en el manual de normas de Debian («Debian
Policy», N. del T.) en Manual
de normas de Debian, 2.5 'Prioridad' la guía de los valores que
deberían tener estos campos.
La prioridad optional se utiliza para paquetes nuevos que no entran en conflicto con otros con prioridad required, important o standard.
La prioridad extra se utiliza para nuevos paquetes que entran en conflicto con otros que no tienen la prioridad extra.
«Section» y «Priority» se usan en las interfaces como dselect
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: », 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», N. del T.) utilizará esta dirección para enviarte los mensajes de los bugs. Evita usar comas, el signo «ampersand» y paréntesis.
La línea 5 incluye la lista de paquetes requeridos para construir tu paquete
(en el campo Build-Depends). Puedes tener una línea adicional
con el campo Build-Depends-Indep (consulta Debian
Policy Manual, 7.7 'Relationships between source and binary packages -
Build-Depends, Build-Depends-Indep, Build-Conflicts,
Build-Conflicts-Indep para más información sobre este campo).
Algunos paquetes como gcc y make están implícitos,
consulta el paquete build-essential para más detalles. Si se
necesita algún compilador no estándar u otra herramienta para construir tu
paquete, deberías añadirla en la línea «Build-Depends». Las entradas
múltiples se separan con comas, lee la explicación de las dependencias
binarias para averiguar más sobre la sintaxis de este campo.
Para todos los paquetes construidos con la orden dh en el archivo
debian/rules, estará debhelper (>=7.0.50~) en el
campo Build-Depends para ajustarse a las normas de Debian respecto
al objetivo clean.
Los paquetes de fuentes que incluyen varios paquetes binarios con el campo Architecture: any se construyen con «autobuilder». Desde el procedimiento «autobuilder» se ejecuta el objetivo debian/rules build el cual, a su vez, instala los paquetes listados en el campo Build-Depends (véase Autobuilder, Sección 6.2), que habitualmente son todos los necesarios de forma que el campo Build-Depends-indep se usa raramente.
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 [19]
Para saber que 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/foo, deberías ejecutar:
$ objdump -p /usr/bin/nombre_paquete | grep NEEDED
y para cada biblioteca listada por la orden anterior (en el ejemplo se hace
para libfoo.so.6) ejecuta
$ dpkg -S libfoo.so.6
Debes utilizar la versión «-dev» de cada uno de los paquetes dentro de la
entrada «Build-deps». 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 requiere 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 del programa.
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 línea 10 describe la arquitectura de CPU para la que el paquete binario
puede ser compilado. Dejaremos puesto «any» (cualquiera), porque
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 El archivo
rules, Sección 4.4 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.)
A continuación se detalla el significado de las dependencias:
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:
Cuando un usuario instale el paquete, todos los programas le informarán de que
puede instalar los paquetes sugeridos. Salvo dpkg y
apt, que ignorarán estas dependencias. Utiliza esto para
paquetes que funcionarán bien con tu programa pero que no son necesarios en
absoluto.
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 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:
Se han definido nombres virtuales para algunos tipos determinados de paquetes
que ofrecen múltiples alternativas para la misma función. Puedes obtener la
lista completa en el fichero
/usr/share/doc/debian-policy/virtual-package-names-list.text.gz.
Usa esto si tu programa ofrece las funciones de un paquete virtual que ya
exista.
Replaces:
Usa esto si tu programa reemplaza ficheros de otro paquete o reemplaza totalmente otro paquete (generalmente se usa conjuntamente con «Conflicts:»). Se eliminarán los ficheros de los paquetes indicados antes de instalar el tuyo.
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. Estas entradas funcionan como variables:
son substituidas por por listas de paquetes cuando debhelper
ejecuta la orden dh_gencontrol(1).
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 y en qué paquetes
están, tales como como libc6 o xlib6g. Luego pasará la lista a
dh_gencontrol(1) que rellenará estas dependencias en el lugar
adecuado (${shlibs:Depends}). De esta forma no tendrás que
preocuparte por esto.
La lista de paquetes generada por dh_perl(1) se usa para
${perl:Depends}.
Algunas órdenes de debhelper determinan las dependencias de los
paquetes listados anteriormente. La lista de estos paquetes se usará para
${misc:Depends}.
Después de decir todo esto, podemos dejar la línea de «Depends:»
exactamente como está ahora e insertar otra línea tras ésta que diga
Suggests: file, porque gentoo utiliza algunas
funciones de este paquete/programa.
La línea 12 es una descripción corta. La mayor parte de los monitores 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 GTK+ 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 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 puede 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 [20].
Vamos a poner los campos Vcs-* documentados en Developer's
Reference, 6.2.5. 'Version Control System location' entre las
lineas 6 y 7. 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 (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
6 Standards-Version: 3.8.4
7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git
8 Vcs-browser: http://git.debian.org/?p=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 a 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 utilises the GTK+ toolkit
30 for its interface.
(He añadido los números de línea)
copyright
Este fichero contiene la información sobre la licencia y copyright de las
fuentes originales del paquete. El formato no está definido en las normas,
pero sí en sus contenidos (Debian
Policy Manual, 12.5 'Copyright information'). También puedes
consultar DEP-5:
Machine-parseable debian/copyright.
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.
Debes completar la información sobre el lugar donde se puede obtener el
código fuente, la condiciones de derechos de autor y la licencia. Las
licencias de código libre más comunes son 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 o la «Artistic
license» y hacer referencia al archivo correspondiente ubicado en el
directorio /usr/share/common-licenses/, que existen en todos los
sistemas Debian. De lo contrario, debe incluirse en el archivo
copyright el texto de la licencia completo.
En resumen, el archivo copyright del paquete gentoo
debería ser similar a esto [21]:
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
2 Name: gentoo
3 Maintainer: Josip Rodin <joy-mg@debian.org>
4 Source: http://sourceforge.net/projects/gentoo/files/
5
6 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
7 License: GPL-2+
8
9 Files: icons/*
10 Copyright: 1998 Johan Hanson <johan@tiq.com>
11 License: GPL-2+
12
13 Files: debian/*
14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
15 License: GPL-2+
16
17 License: GPL-2+
18 This program is free software; you can redistribute it and/or modify
19 it under the terms of the GNU General Public License as published by
20 the Free Software Foundation; either version 2 of the License, or
21 (at your option) any later version.
22 .
23 This program is distributed in the hope that it will be useful,
24 but WITHOUT ANY WARRANTY; without even the implied warranty of
25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
26 GNU General Public License for more details.
27 .
28 You should have received a copy of the GNU General Public License along
29 with this program; if not, write to the Free Software Foundation, Inc.,
30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
31 .
32 On Debian systems, the full text of the GNU General Public
33 License version 2 can be found in the file
34 `/usr/share/common-licenses/GPL-2'.
(He añadido los números de línea)
Por favor, sigue el COMO redactado por «ftpmasters» y enviada a
«debian-devel-announce»: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html.
changelog
Este es un fichero requerido, que tiene un formato especial descrito en las
normas Debian, Debian
Policy Manual, 4.4 'debian/changelog'. Este es el formato que usan
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 crea uno por omisión, el cual es como sigue:
1 gentoo (0.9.12-1) unstable; urgency=low
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)
La línea 1 es el nombre del paquete, versión, distribución y urgencia. El nombre debe coincidir con el nombre del paquete fuente, la distribución debería ser, por ahora, «unstable» (o incluso «experimental») [22] y la urgencia no debería cambiarse a algo mayor que low. :-)
Las línea 3-5 son una entrada de registro, donde se documentan los cambios
hechos en esta revisión del paquete (no los cambios en las fuentes originales
- hay un fichero especial para este propósito, creado por los autores
originales y que instalarás luego como
/usr/share/doc/gentoo/changelog.gz). En el ejemplo se supone que
el código del informe de error ITP («Intent To Package», intento de
empaquetar) es #12345. Las nuevas líneas deben insertarse justo
antes de la línea que hay más arriba que comienza por un asterisco («*»).
Puede hacerlo con dch(1), o manualmente con cualquier editor de
texto.
Terminarás con algo así:
1 gentoo (0.9.12-1) unstable; 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)
Puedes leer más sobre cómo actualizar el fichero changelog más adelante en Actualizar el paquete, Capítulo 9.
rules
Ahora necesitamos mirar las reglas exactas que
dpkg-buildpackage(1) utilizará para crear el paquete. Este
fichero es en realidad otro Makefile, pero diferente al que viene
en las fuentes originales. A diferencia de otros ficheros en
debian, éste debe ser un fichero ejecutable.
rules
Cada fichero «rules» (de reglas, N. del T.), como muchos otros Makefiles, se
compone de varias reglas que especifican cómo tratar las fuentes.Debian
Policy Manual, 4.9 'Main building script: debian/rules' explica
detalladamente su función.
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.
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). [23]
binary-arch (obligatorio): para la construcción de paquetes
dependientes de la arquitectura («arch-dependent» los que tienen el campo del
archivo control Architecture: any) [24]
binary-indep (obligatorio): para la construcción de paquetes
independientes de la arquitectura (Architecture: all en el archivo
control). [25]
get-orig-source (opcional): para obtener la versión más reciente de las fuentes originales desde el lugar de almacenaje del autor.
Cada regla se compone de objetivos, ficheros o nombres de acciones que se deben llevar a cabo (por ejemplo, «build:» o «install:»). Las reglas que quieras ejecutar deberían llamarse como argumentos de la línea de órdenes (por ejemplo, «./debian/rules build» o «make -f rules install»). Después del nombre del objetivo, puedes nombrar las dependencias, programas o ficheros de los que la regla dependa. Después de esto, hay un número cualquiera de instrucciones (¡indentado con <tab>!), hasta que se llega a una línea en blanco. Ahí empieza otra regla. Las líneas múltiples en blanco, y las líneas que empiezan por almohadillas («#») se tratan como comentarios y se ignoran.
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. Deberías
leer también la entrada de «make» en info para más información.
rules predeterminado
La nueva versión de dh_make genera un un archivo
rules muy simple pero poderoso utilizando la orden
dh:
1 #!/usr/bin/make -f
2 # -*- makefile -*-
3 # Sample debian/rules that uses debhelper.
4 # This file was originally written by Joey Hess and Craig Small.
5 # As a special exception, when this file is copied by dh-make into a
6 # dh-make output file, you may use that output file without restriction.
7 # This special exception was added by Craig Small in version 0.37 of dh-make.
8
9 # Uncomment this to turn on verbose mode.
10 #export DH_VERBOSE=1
11
12 %:
13 dh $@
(He añadido los números de línea. En el fichero debian/rules
los espacios iniciales de las líneas son códigos de tabulación)
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 10 debe descomentarse para asignar el valor 1 a la variable
DH_VERBOSE. En ese caso, se escribirán las órdenes
dh_* que 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 la herramientas debhelper y no te esconde
nada.
Todo el trabajo del archivo se reduce a las líneas 12 y 13. El símbolo de
porcentaje substituye a cualquier objetivo para a continuación ejecutar
únicamente dh con el nombre del objetivo (como opción) [26]. La orden dh es
un guión que ejecuta las secuencias necesarias de órdenes dh_*
según sus parámetros, como se describe a continuación [27]:
debian/rules clean ejecuta dh clean, que a su vez ejecuta lo siguiente:
dh_testdir
dh_auto_clean
dh_clean
debian/rules build ejecuta dh build, que a su vez ejecuta lo siguiente:
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
fakeroot debian/rules binary ejecuta fakeroot dh binary, que a su vez ejecuta lo siguiente [28]:
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_pysupport
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 ejecuta fakeroot dh binary-arch; que a su vez ejecuta la misma secuencia que fakeroot dh binary pero con la opción -a para cada orden.
fakeroot debian/rules binary-indep ejecuta fakeroot dh
binary-indep; que a su vez ejecuta casi la misma secuencia que
fakeroot dh binary puesto que excluye la ejecución de
dh_strip, dh_makeshlibs y dh_shlibdeps a
la vez que ejecuta el resto de órdenes añadiendo la opción -i.
La función de las órdenes dh_* puede deducirse de su nombre [29]. 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 [30].
dh_auto_clean ejecuta
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. [31]
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 crea
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. Lo único que no debes cambiar son los nombres de
las reglas, puesto que todas las herramientas los utilizan, como se especifica
en la normas de Debian.
A pesar de que install no es un objetivo obligatorio, se contempla
su uso. fakeroot dh install se comporta como fakeroot dh
binary pero se detiene después de dh_fixperms.
rules
Puedes realizar muchos cambios para adaptar el archivo rules
construido por la orden dh.
La orden dh $@ permite las siguientes adaptaciones [32]:
Añadir funcionalidad para la orden dh_pysupport (la mejor opción
para Python) [33].
Añade el paquete python-support en el campo
Build-Depends del archivo control.
No cambia el uso de dh $@ (es la opción predeterminada).
Esto gestiona el módulo Python utilizando las funcionalidades de
python-support.
Añadir funcionalidad para la orden dh_pycentral.
Añade el paquete python-central en el campo
Build-Depends del archivo control.
Utiliza dh --with python-central $@ en lugar de dh $@.
Esto desactiva la orden dh_pysupport.
Esto gestiona el módulo Python utilizando las funcionalidades de
python-central.
Añadir funcionalidad para la orden dh_installtex.
Añade el paquete tex-common en el campo
Build-Depends del archivo control.
Utiliza dh --with tex $@ en lugar de dh $@.
Esto registra las fuentes «Type 1», los patrones de separación de palabras («hyphenation patterns») o los formatos TeX.
Añadir funcionalidad para las órdenes dh_quilt_patch y
dh_quilt_unpatch.
Añade el paquete quilt en el campo Build-Depends del
archivo control.
Utiliza dh --with quilt $@ en lugar de dh $@.
Esto aplican o elimina 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 funcionalidad para la orden dh_dkms.
Añade el paquete dkms en el campo Build-Depends del
archivo control.
Utiliza dh --with dkms $@ en lugar de dh $@.
Esto se controla correctamente el uso de DKMS [34] en la construcción de paquetes del núcleo.
Añadir funcionalidad para la orden dh_autotools-dev_updateconfig
y dh_autotools-dev_restoreconfig.
Añade el paquete autotools-dev en el campo
Build-Depends del archivo control.
Utiliza dh --with autotools-dev $@ en lugar de dh $@.
Esto actualiza y restaura config.sub y config.guess.
Añadir funcionalidad para la orden dh_autoreconf y
dh_autoreconf_clean.
Añade el paquete dh-autoreconf en el campo
Build-Depends del archivo control.
Utiliza dh --with autoreconf $@ en lugar de dh $@.
Así se actualiza los archivos del sistema de compilación GNU y los restaura después de la compilación.
Añadir la funcionalidad de autocompletar a bash.
Añade el paquete bash-completion en el campo
Build-Depends del archivo control.
Utiliza dh --with bash-completion $@ en lugar de dh $@.
Esto instala la función autocompletar de bash utilizando el
archivo de configuración de
debian/nombre_paquete.bash-completion.
Para las fuentes que usan «Autotools», combinar las opciones anteriores con dh --with autotools-dev --with autoreconf $@ es lo habitual con el sistema de compilación GNU.
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 Otros
ficheros en el directorio debian., Capítulo 5 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_foo con las reglas a ejecutar en
el archivo rules sólo para la orden
dh_foo que vas a cambiar. Se trata de decir
«ejecútame a mí en su lugar» [35].
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 [36]:
override_dh_auto_configure:
dh_auto_configure -- --sysconfig=/etc/gentoo
Los argumentos a continuación de -- se añaden a los argumentos
predeterminados, anulándolos, en la ejecución automática del programa. Es
mejor utilizar la orden dh_auto_configure que el
./configure ya que así sólo anulará el argumento
--sysconfig manteniendo intactos otros argumentos de
./configure.
Si el Makefile de las fuentes de gentoo requiere la
especificación del objetivo build para compilarlo [37], 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 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 [38].
override_dh_installchangelogs:
dh_installchangelogs FIXES
Cuando utilizas el nuevo programa dh, la utilización explícita
de objetivos como los listados en Objetivos del archivo
rules, Sección 4.4.1 (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).
[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ siguiente ]
Guía del nuevo desarrollador de Debian
versión 1.2.25, 2010-12-21 14:06:56 UTCjoy-mg@debian.orgjfs@debian.orgender@debian.organa@debian.orgfcocuadrado@gmail.comtangram.peces@gmail.com