[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ siguiente ]
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.
Este fichero contiene varios valores que dpkg
,
dselect
y otras herramientas de gestión de paquetes usarán para
gestionar el paquete.
Aquí está el fichero de control que dh_make crea para nosotros:
1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.6.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <insertar hasta 60 caracteres de descripción> 12 <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, N. del T.) (el software libre), «non-free» (no libre, N. del T.) (el software que realmente no es libre) y «contrib» (software libre que depende de software no libre). 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.
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.) la guía de los valores que deberían tener estos campos. La prioridad «optional» suele ser lo mejor para los paquetes nuevos.
«Section» y «Priority» se usan en las interfaces como dselect
cuando ordenan los paquetes. Una vez que envies 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, N. del T.).
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 despueé 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 «&» y paréntesis.
La línea 5 incluye la lista de paquetes requeridos para construir tu paquete.
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.
También tienes los campos «Build-Depends-Indep» y «Build-Conflicts» entre otros. Estos datos los usarán los programas de construcción automática de paquetes de Debian para crear paquetes binarios para el resto de arquitecturas. Consulta las normas de Debian para más información sobre las dependencias de construcción y la Referencia del Desarrollador para más información sobre las otras arquitecturas y sobre cómo migrar los programas a ellas.
Aquí tienes un truco que puedes usar para averiguar qué paquetes necesitará tu paquete en su construcción:
strace -f -o /tmp/log ./configure # o make en lugar de ./configure, si el paquete no usa autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done
Para encontrar manualmente las dependencias exactas de
/usr/bin/foo
, ejecuta
objdump -p /usr/bin/foo | grep NEEDED
y para cada biblioteca, por ejemplo, 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.
La línea 8 es el nombre del paquete binario. Este suele ser el mismo que el del paquete fuente, pero no tiene que ser necesariamente así siempre.
La línea 9 describe la arquitectura de CPU para la que el paquete binario puede
ser compilado. Dejaremos puesto «any» (cualquiera, N. del T.), 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 fichero «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 10 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, N. del T.) otros campos de relación son «Recommends:» (recomienda, N. del T.), «Suggests:» (sugiere, N. del T.), «Pre-Depends:» (predepende de, N. del T.), «Conflicts:» (entra en conflicto con, N. del T.), «Provides:» (provee, N. del T.), «Replaces:» (reemplaza a, N. del T.).
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:
Programas como dselect o aptitude informarán en la instalación de los paquetes recomendados por tu paquete, dselect incluso insistirá. dpkg y apt-get ignorarán este campo. Usa esto para paquetes que no son estrictamente necesarios pero que se usan habitualmente con tu programa.
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é instalados y correctamente configurados. Utiliza esto muy poco y sólo después de haberlo discutido en la lista de distribución de debian-devel. 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.
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). 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. De esta forma no tendrás que preocuparte por esto.
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 11 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 12 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.
Aquí está el fichero de control actualizado:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable X file manager using GTK+ 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the «file» command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter).
(He añadido los números de línea).
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 (sección 12.6 «Copyright information»).
dh_make crea por omisión un fichero como este:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <rellena con el sitio ftp site> 5 6 Upstream Author(s): <pon el nombre del autor y dirección de correo> 7 8 Copyright: 9 10 <Debe incluirse aquí>
(He añadido los números de línea).
Las cosas importantes que se deben añadir a este fichero son el lugar de donde obtuviste el paquete junto con la nota de copyright y licencia originales. Debes incluir la licencia completa, a menos que sea una licencia común en el mundo del software libre como GNU GPL o LGPL, BSD o la «Licencia artística», donde basta referirse al fichero apropiado en el directorio /usr/share/common-licenses/ que existe en todo sistema Debian.
Gentoo está publicado bajo la Licencia Pública General GNU, así que cambiaremos el fichero a esto:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License either version 2 of the License, 13 or (at your option) any later version. 14 On Debian systems, the complete text of the GNU General Public 15 License can be found in the file `/usr/share/common-licenses/GPL-2'.
(He añadido los números de línea).
Por favor, sigue el COMO de debian-devel-announce: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
.
(Nota del T.: las normas actuales de Debian actuales indican que los documentos aquí citados estén escritos en inglés, al ser el idioma oficial del proyecto, por lo que no se traducen en este documento).
Este es un fichero requerido, que tiene un formato especial descrito en las normas, sección 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. 4 5 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +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») 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). 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. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +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.
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 necesita
ser un fichero ejecutable.
Cada fichero «rules» (de reglas, N. del T.), como muchos otros Makefiles, se compone de varias reglas que especifican cómo tratar las fuentes. 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.
La parte importante que debes conocer sobre el fichero de reglas creado por dh_make, es que sólo es una sugerencia. Funcionará para paquetes simples pero para más complicados, no te asustes y añade o quita cosas de éste para ajustarlo a tus necesidades. Una cosa que no debes cambiar son los nombres de las reglas, porque todas las herramientas utilizan estos nombres, como se describe en las normas.
Éste es, más o menos, el contenido del fichero debian/rules que dh_make genera por omisión:
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 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure
(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)
(N. del T.: se han traducido los comentarios del fichero de reglas, pero en el fichero generado por dh_make estarán en inglés)
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.
El significado de las variables DH_* que se mencionan en las líneas 8 y 9
debería ser evidente de la descripción corta. Para más información sobre
DH_COMPAT consulte la sección «Debhelper compatibility levels» del manual de
debhelper(1)
.
Las líneas de la 11 a la 16 son el esqueleto de apoyo para los parámetros de DEB_BUILD_OPTIONS, descritos en las normas sección 10.1 «Binarios». Basicamente, estas cosas controlan si los binarios se construyen con los símbolos del depurador y si deberían eliminarse tras la instalación. De nuevo, es sólo un esqueleto, una pista de lo que deberías hacer. Deberías comprobar cómo el sistema de construcción de las fuentes maneja la inclusión de los símbolos del depurador y su eliminación en la instalación e implementarlo por ti mismo.
Habitualmente puedes decirle a gcc que compile con "-g" usando la variable CFLAGS. Si este es el caso de tu paquete, pon la variable añadiendo CFLAGS="$(CFLAGS)" a la invocación de $(MAKE) en la regla de construcción (ver más abajo). Alternativamente, si tu paquete usa un guión de configuración de autoconf puedes definir la cadena arriba mostrada anteponiéndola a la llamada a ./configure en la regla de construcción.
Los programas a los que se le quitan los símbolos del depurador con
strip
se configuran normalmente para instalarse sin pasar por
strip
, y a menudo sin una opción para cambiar esto.
Afortunadamente, tienes dh_strip(1)
que detectará cuando la
bandera (N. del T., «flag») DEB_BUILD_OPTIONS=nostrip está activada y
finalizará silenciosamente.
Las líneas 18 a la 26 describen la regla build (y su hija «build-stamp»), que
ejecuta make con el propio Makefile de la aplicación para compilar el programa.
Si el programa utiliza las utilidades de configuración de GNU para construir
los binarios, por favor, asegúrate de leer
/usr/share/doc/autotools-dev/README.Debian.gz
. Hablaremos sobre
el ejemplo comentado docbook-to-man más adelante en manpage.1.ex, manpage.sgml.es, Sección
5.8.
La regla «clean» (limpiar, N. del T.), como se especifica en las líneas 28 a la 36, limpia cualquier binario innecesario o cosas generadas automáticamente, dejadas después de la construcción del paquete. Esta regla debe funcionar en todo momento (¡incluso cuando el árbol de fuentes esté limpio!), así que, por favor, usa las opciones que fuercen a hacer cosas (por ejemplo para rm, sería «-f»), o ignora los valores devueltos (con un «-» al principio de la orden).
El proceso de instalación, la regla «install», comienza en la línea 38. Básicamente ejecuta la regla «install» del Makefile del programa, pero lo instala en el directorio $(CURDIR)/debian/gentoo. Esta es la razón por la que especificamos $(DESTDIR) como el directorio raíz de instalación del Makefile de gentoo.
Como sugiere el comentario, la regla «binary-indep», en la línea 48, se usa para construir paquetes independientes de arquitectura. Como no tenemos ninguno, aquí no se hará nada.
Lo siguiente es la regla «binary-arch», en las líneas 52 a 79, en la que ejecutamos varias pequeñas utilidades del paquete debhelper que nos permiten hacer diversas operaciones en nuestro paquete para que cumpla las normas de Debian.
Si tu paquete es del tipo «Architecture: all» necesitarás incluir todas las órdenes para crear el paquete bajo esta regla, y dejar la siguiente regla («binary-arch») vacía en su lugar.
Los nombres comienzan con dh_ y el resto del nombre es la descripción de lo que la utilidad en particular realmente hace. Es todo más o menos auto-explicativo, pero a continuación tienes algunos añadidos a las explicaciones:
dh_testdir(1)
comprueba que estás en el directorio correcto (esto
es, el directorio raíz de la distribución de las fuentes),
dh_testroot(1)
comprueba que tienes permisos de superusuario que
son necesarios para las reglas «binary-arch», «binary-indep» and «clean»,
dh_installman(1)
copiará todas las páginas de manual que encuentre
en el paquete fuente en el paquete, sólo has de indicarle donde están de forma
relativa, desde el nivel más alto del directorio de codigo.
dh_strip(1)
elimina las cabeceras de depuración de los ficheros
ejecutables para hacerlos más pequeños,
dh_compress(1)
comprime las páginas de manual y los ficheros de
documentación que sean más grandes de 4 kB con gzip(1)
,
dh_installdeb(1)
copia los ficheros relativos al paquete (es
decir, los guiones del desarrollador que mantiene el paquete) bajo el
directorio debian/gentoo/DEBIAN
,
dh_shlibdeps(1)
calcula las dependencias de los ejecutables y
bibliotecas con las bibliotecas compartidas,
dh_gencontrol(1)
genera e instala el fichero de control en
debian/gentoo/DEBIAN
,
dh_md5sums(1)
genera las sumas de comprobación MD5 para todos los
ficheros del paquete.
Para información más completa de lo que hacen cada uno de estos guiones dh_* , y qué otras opciones tienen, por favor lee sus páginas de manual respectivas. Hay otros guiones con la misma nomenclatura (dh_*) que no se han mencionado aquí, pero pueden serte útiles. Si los necesitas, lee la documentación de debhelper.
La sección binary-arch es en una de las que deberías comentar o eliminar las líneas que llamen a funciones que no necesites. Para gentoo, comentaré de ejemplos, cron, init, man e info, simplemente porque gentoo no las necesita. Tan sólo, en la línea 68, reemplazaré «ChangeLog» con «FIXES», porque este es el nombre del fichero de cambios de las fuentes.
Las últimas dos líneas (junto con otras que no se explican) son cosas más o menos necesarias, sobre las que puedes leer en el manual de make, y las normas. Por ahora no es importante que sepas nada de ellas.
[ anterior ] [ Contenidos ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ siguiente ]
Guía del nuevo desarrollador de Debian
version 1.2.11, 12 de enero de 2007.joy-mg@debian.org
jfs@debian.org
ender@debian.org
ana@debian.org