Provided by: dpkg-dev_1.16.1.2ubuntu7_all bug

NOMBRE

       dpkg-gensymbols  -  Generacion  de ficheros <<symbols>> (informacion de
       dependencia de bibliotecas compartidas)

SINOPSIS

       dpkg-gensymbols [option...]

DESCRIPCI'ON

       dpkg-gensymbols   analiza   un   arbol   temporal    de    construccion
       (<<debian/tmp>>  por  omision)  en busca de bibliotecas para generar un
       fichero symbols que los describa. Este fichero, si no  esta  vacio,  se
       instala  en el subdirectorio <<DEBIAN>> del arbol de construccion, para
       despues incluir el contenido en la informacion de control del paquete.

       Al generar  estos  ficheros,  usa  algunos  ficheros  <<symbols>>  como
       entrada  proporcionados  por  el  desarrollador.  Busca  los siguientes
       ficheros, usando el primero que encuentra.

       o   debian/package.symbols.arch

       o   debian/symbols.arch

       o   debian/package.symbols

       o   debian/symbols

       La meta principal de estos ficheros es proporcionar la  version  minima
       asociada   a   cada   simbolo   proporcionado   por   las  bibliotecas.
       Habitualmente, se corresponde con la primera version de ese paquete que
       proporciona  el  simbolo,  pero  el  desarrollador lo puede incrementar
       manualmente  si  la  ABI  del  simbolo  se  extiende  sin   romper   la
       compatibilidad  con  versiones  anteriores.  Es  la responsabilidad del
       desarrollador que estos ficheros esten al dia y  que  sean  apropiados,
       pero dpkg-gensymbols le asiste en esta tarea.

       Cuando  los  ficheros  <<symbols>> generados difieren del proporcionado
       por el desarrollador, dpkg-gensymbols mostrara  las  diferencias  entre
       ambas versiones. Mas aun, puede que falle si la diferencia es demasiado
       grande, (puede configurar cuanta diferencia tolerar, consulte la opcion
       -c).

MANTENER FICHEROS <<SYMBOLS>>

       Los  ficheros  <<symbols>> son realmente utiles solo cuando reflejan la
       evolucion del paquete a lo largo de varias publicaciones. Por ello,  el
       desarrollador  tiene que actualizarlos cada vez que se anada un simbolo
       nuevo, para que  asi  la  minima  version  asociada  concuerde  con  la
       realidad.  Para  hacer  esto  apropiadamente  puede  usar  los <<diff>>
       contenidos en los registros de construccion. En la mayoria de los caso,
       el    <<diff>>    se    aplica    directamente    sobre    el   fichero
       <<debian/package.symbols>>.  Dicho  esto,  es  necesario  afinar   este
       proceso:  se recomienda, por ejemplo, eliminar el numero de revision de
       Debian de la version minima para que asi  aquellas  adaptaciones  hacia
       atras (<<backports>>) con un numero de version menor, pero con la misma
       version que la fuente  original,  puedan  satisfacer  las  dependencias
       generadas.  Si  no  se  puede  eliminar la revision de Debian porque el
       simbolo se anadio debido a un cambio especifico de Debian puede  afijar
       <<~>> a la version.

       Antes  de  aplicar  un  parche  al fichero <<symbols>> el desarrollador
       deberia revisar nuevamente que es adecuado. Se espera que los  simbolos
       publicos  no  desaparezcan  asi que, idealmente, el parche solo deberia
       anadir lineas nuevas.

       Note that you can put comments in symbols files: any line with  '#'  as
       the  first  character  is a comment except if it starts with '#include'
       (see section Using  includes).  Lines  starting  with  '#MISSING:'  are
       special comments documenting symbols that have disappeared.

   Usar la sustituci'on de #PACKAGE#
       En  algunos  casos  aislados  el nombre de la biblioteca varia segun la
       arquitectura. Puede usar el marcador #PACKAGE#  para  evitar  incrustar
       (<<hardcode>>)  el  nombre  del  paquete  en el fichero <<symbols>>. Se
       reemplazara por el nombre real del paquete durante  la  instalacion  de
       los ficheros <<symbols>>. A diferencia del marcador #MINVER#, #PACKAGE#
       nunca aparecera en un  fichero  <<symbols>>  contenido  en  un  paquete
       binario.

   Usar etiquetas de s'imbolos
       El etiquetado de simbolos es util para marcar aquellos simbolos que son
       de alguna  manera  especiales.  Cada  simbolo  puede  tener  un  numero
       arbitrario  de etiquetas asociadas a este. Aunque se analizan y guardan
       todas las etiquetas, dpkg-gensymbols solo entiende algunas de ellas,  e
       iniciara   un   tratamiento  especial  de  los  simbolos.  Consulte  la
       sub-seccion Etiquetas est'andar de s'imbolos para una referencia de estas
       etiquetas.

       La  especificacion de la etiqueta aparece a continuacion del nombre del
       simbolo (no se permite un espacio vacio entre estos). Siempre  comienza
       con  un  parentesis de apertura (, finaliza con un parentesis de cierre
       ), y debe contener al menos una etiqueta. Varias etiquetas  se  separan
       con  un  caracter  |. Opcionalmente, cada etiqueta puede tener un valor
       separado del nombre de la etiqueta mediante el caracter =. Los  nombres
       de  etiqueta  y  valores pueden ser cadenas arbitrarias, a excepcion de
       que no pueden contener ningun caracter especial: ), | y =. Los  nombres
       de  simbolo  a continuacion de una especificacion de etiqueta se pueden
       entrecomillar con caracteres ' o ", permitiendo  asi  espacios  vacios.
       Por  otra  parte,  de  no  existir  ninguna  etiqueta  definida para el
       simbolo, las comillas se trataran como parte del  nombre  del  simbolo,
       continuando hasta el primer espacio.

        (tag1=tengo una marca|nombre de etiqueta con espacio)"simbolo
        entrecomillado y etiquetado"@Base 1.0
        (optional)simbolo_sin_comillas_y_etiquetado@Base 1.0 1
        simbolo_sin_etiquetar@Base 1.0

       El  primer  simbolo  del  ejemplo  se  llama  s'imbolo  entrecomillado y
       etiquetado, y tiene dos etiquetas: tag1, con el valor tengo una marca y
       nombre  de etiqueta con espacio, que no tiene valor. El segundo simbolo
       se llama s'imbolo_sin_comillas_y_etiquetado, y solo tiene  una  etiqueta
       llamada  optional. El ultimo simbolo es un ejemplo de un simbolo normal
       sin etiquetar.

       Debido a que las etiquetas de simbolos son una  extension  del  formato
       deb-symbols(5)  solo pueden formar parte de los ficheros <<symbols>> de
       paquetes fuente  (estos  ficheros  deberian  aparecer  como  plantillas
       usadas  para  generar  los  ficheros <<symbols>> integrados en paquetes
       binarios). Cuando invoca dpkg-gensymbols con la opcion -t, enviara  por
       la   salida   ficheros   <<symbols>>   compatibles   con   el   formato
       deb-symbols(5): procesa completamente los simbolos  de  acuerdo  a  los
       requerimientos de sus etiquetas estandar, y elimina todas las etiquetas
       de la salida. Por otra parte, en el  modo  plantilla  (-t),  todos  los
       simbolos  y  etiquetas  (estandar  y  desconocidos)  se muestran por la
       salida, y se escriben en su forma original a medida que se cargan.

   Etiquetas de s'imbolo est'andar
       optional
              Un  simbolo  marcado  como  opcional  puede  desaparecer  de  la
              biblioteca   en   cualquier  momento  sin  causar  un  fallo  de
              dpkg-gensymbols.  Por  otra  parte,  los   simbolos   opcionales
              desaparecidos    apareceran   continuamente   como   <<MISSING>>
              (ausente) en el <<diff>> de cada  nueva  revision  del  paquete.
              Este   comportamiento   sirve   como  un  recordatorio  para  el
              desarrollador para informar de  la  necesidad  de  eliminar  tal
              simbolo  del  fichero <<symbols>>, o de anadir este nuevamente a
              la biblioteca. Cuando el simbolo opcional declarado  previamente
              como  <<MISSING>>  reaparece de subito en la siguiente revision,
              se actualizara  a  un  estado  <<existente>>  sin  modificar  la
              version minima.

              Esta  etiqueta  es  util  para  aquellos  simbolos privados cuya
              desaparicion no  rompe  la  ABI.  Por  ejemplo,  la  mayoria  de
              plantillas   de   produccion   de   un   objeto   definido   mas
              especificamente por medio del reemplazo de ciertas variables por
              valores  (<<instantiation>>) de C++ se encuentran dentro de esta
              categoria. Al igual que con cualquier otra etiqueta, este  puede
              tener  un valor arbitrario: se puede usar para indicar porque el
              simbolo se considera opcional.

       arch=lista-de-arquitecturas
              Esta etiqueta permite limitar el conjunto de arquitecturas donde
              se  supone que el simbolo existe. Cuando la lista de simbolos se
              actualiza con los simbolos descubiertos en la biblioteca,  todos
              los   simbolos   especificos  de  la  arquitectura  que  no  son
              relevantes para la  arquitectura  anfitrion  se  toman  como  no
              existentes.  Si  un  simbolo  especifico  a  la arquitectura que
              concuerda con la arquitectura anfitrion presente no existe en la
              biblioteca,   se  aplicaran  los  procedimientos  normales  para
              simbolos desaparecidos, llevando a  que  dpkg-gensymbols  falle.
              Por  otra  parte,  si el simbolo especifico a la arquitectura se
              encuentra  cuando  se  suponia  que   no   existe   (porque   la
              arquitectura anfitrion presente no esta listada en la etiqueta),
              pasa a ser neutral a la arquitectura (por ejemplo, se elimina la
              etiqueta  de arquitectura, apareciendo el simbolo en el <<diff>>
              debido a la  modificacion),  pero  no  se  toma  como  un  nuevo
              simbolo.

              Al  operar  en  el  modo  por  omision  (sin  plantilla) solo se
              escribiran al fichero <<symbols>> aquellos simbolos  especificos
              a  la  arquitectura que coinciden con la arquitectura anfitrion.
              Por  otra  parte,  en  el  modo  plantilla  todos  los  simbolos
              especificos   a   la   arquitectura   (incluyendo  arquitecturas
              alternativas) siempre se escribiran al fichero <<symbols>>.

              El formato de lista-de-arquitecturas es el mismo que el usado en
              el  campo  Build-Depends  de  debian/control (a excepcion de los
              parentesis cuadrados de cierre <<[]>>). Por ejemplo,  el  primer
              simbolo  de  la  lista a continuacion se considerara solo en las
              arquitecturas alpha, amd64, kfreebsd-amd64 y ia64, mientras  que
              el segundo en todos menos armel.

               (arch=alpha      amd64      kfreebsd-amd64      ia64)un_simbolo
              _especifico_64bit@Base 1.0
               (arch=!armel)simbolo_que_armel_no_tiene@Base 1.0

       ignore-blacklist
              dpkg-gensymbols tiene una lista negra interna de simbolos que no
              deberian   aparecer   en   los   ficheros  <<symbols>>,  ya  que
              habitualmente son solo efectos secundarios de  los  detallas  de
              implementacion de la cadena de herramientas. Si por alguna razon
              desea incluir uno de esos simbolos  en  el  fichero  <<symbols>>
              deberia  etiquetar  el  simbolo  con ignore-blacklist. Puede ser
              necesario con alguna cadena de herramientas de bajo  nivel  como
              libgcc.

       c++    Denota el patron c++- Consulte la subseccion a continuacion Usar
              patrones de s'imbolos.

       symver Denota el patron  de  simbolos  symver  (version  del  simbolo).
              Consulte   la   sub-seccion  a  continuacion  Usar  patrones  de
              s'imbolos.

       regex  Denota el patron de simbolos regex (expresion regular). Consulte
              la sub-seccion a continuacion Usar patrones de s'imbolos.

   Usar patrones de s'imbolos.
       A  diferencia  de  cualquier  definicion  de simbolo estandar un patron
       puede cubrir varios simbolos reales de la  biblioteca.  dpkg-gensymbols
       intentara  emparejar  cada patron con cada simbolo real que no tiene un
       simbolo especifico de contrapartida definido en el fichero de simbolos.
       En  el momento que se encuentre el primer patron que coincida se usaran
       todas sus  etiquetas  y  propiedades  como  un  definicion  basica  del
       simbolo.  Si  ninguno de los patrones encaja, el simbolo se considerara
       nuevo.

       Un patron se considera perdido si no encaja con ningun  simbolo  en  la
       biblioteca.  Por  omision,  esto  accionara un fallo de dpkg-gensymbols
       bajo -c1 o un nivel superior. Aun asi, si no  desea  la  aparicion  del
       fallo, puede marcar el patron con la etiqueta optional. Entonces, si el
       patron no encaja con nada simplemente aparecera  en  el  <<diff>>  como
       <<MISSING>>. Aun mas, al igual que con cualquier simbolo, puede limitar
       el patron a unas arquitecturas definidas con la etiqueta arch. Consulte
       la seccion anterior Etiquetas de s'imbolo est'andar.

       Los  patrones  son una extension del formato deb-symbols(5), y por ello
       solo son validos en plantillas de fichero de simbolos. Por otra  parte,
       la  parte  del nombre del simbolo definido sirve como una expresion que
       se comparara  con  el  nombre@versi'on  del  simbolo  real.  Para  poder
       distinguir  entre  los  diferentes  tipos de patron, este se etiquetara
       habitualmente con una etiqueta especial.

       A dia de hoy, dpkg-gensymbols es compatible con tres tipos de  patrones
       basicos:

       c++
          Este patron se indica con la etiqueta c++. Solo encaja con el nombre
          <<demangled>> de simbolos C++ (tal y  como  muestra  la  herramienta
          c++filt(1)).  Este patron es de utilidad para emparejar simbolos con
          nombres  <<mangled>>  que  pueden  variar  segun  la   arquitectura,
          mientras  que  sus  nombres <<demangled>> permanecen sin cambios. Un
          grupo de estos simbolos son  los  thunk  no  virtuales,  que  tienen
          direcciones  relativas  (<<offsets>>)  especificas a la arquitectura
          integradas en sus nombres <<mangled>>. Un ejemplo comun de este caso
          es un destructor virtual, que bajo una herencia de diamante necesita
          un   simbolo   thunk   no   virtual.   Por   ejemplo,   incluso   si
          <<_ZThn8_N3NSB6ClassDD1Ev@Base>>   en   arquitecturas  de  32bit  es
          <<_ZThn16_N3NSB6ClassDD1Ev@Base>> en arquitecturas de  64bit,  puede
          emparejarlo con un unico patron c++:

          libdummy.so.1 libdummy1 #MINVER#
           [...]
           (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
           [...]

          Puede   obtener   el   nombre  <<demangled>>  del  ejemplo  anterior
          ejecutando la siguiente orden:

           $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt

          Observe que aunque el nombre <<mangled>> sea por definicion unico en
          la   biblioteca,   no   es   necesariamente   cierto   para  nombres
          <<demangled>>. Puede que dos simbolos reales y distintos  tengan  el
          mismo nombre <<demangled>>. Por ejemplo, en caso de existir simbolos
          thunk no virtuales en complejas configuraciones de herencia,  o  con
          la mayoria de constructores y destructores (ya que habitualmente g++
          genera dos simbolos para ellos). Por otra  parte,  estas  colisiones
          aparecen  al  nivel  de  la  ABI, y por ello no deberian degradar la
          calidad del fichero de simbolos.

       symver
          La  etiqueta  symver  indica  este  patron.  Las  bibliotecas   bien
          mantenidas   tienen   simbolos   con  version,  donde  cada  version
          corresponde con la version del autor original en la que se anadio el
          simbolo.  De  ser asi, puede usar un patron symver para emparejar el
          simbolo asociado con una version en particular. Por ejemplo:

          libc.so.6 libc6 #MINVER#
           (symver)GLIBC_2.0 2.0
           [...]
           (symver)GLIBC_2.7 2.7
           access@GLIBC_2.0 2.2

          Todos los simbolos  asociados  con  las  versiones  <<GLIBC_2.0>>  y
          <<GLIBC_2.7>>   llevan   a   una   version   minima  de  2.0  y  2.7
          respectivamente, con la excepcion del simbolo  <<access@GLIBC_2.0>>.
          El  segundo  lleva  a una dependencia minima sobre la version 2.2 de
          libc6,   a   pesar   de   estar   en    el    rango    del    patron
          <<(symver)GLIBC_2.0>>,  debido  a que los simbolos especificos tiene
          precedencia sobre los patrones.

          Tenga en cuanta que los patrones de comodin antiguos (indicados  por
          <<*@versio>>   en   el   campo  del  nombre  del  simbolo)  son  aun
          compatibles, aunque han quedado obsoletos por  el  nuevo  estilo  de
          sintaxis <<(symver|optional)version>>. Por ejemplo, deberia escribir
          <<*@GLIBC_2.0 2.0>> como <<(symver|optional)GLIBC_2.0 2.0>> si desea
          el mismo comportamiento.

       regex
          Los  patrones  de  expresiones  regulares se indican con la etiqueta
          regex.  Buscan  coincidencias  con  la  expresion  regular  de  perl
          definido en el campo de nombre del simbolo. Una expresion regular se
          empareja tal cual, por ello no olvide insertar ^  al  inicio  de  la
          misma o puede que coincida con cualquier parte de la cadena real del
          simbolo nombre@versi'on. Por ejemplo:

          libdummy.so.1 libdummy1 #MINVER#
           (regex)"^mystack_.*@Base$" 1.0
           (regex|optional)"private" 1.0

          Los  simbolos  como   <<mystack_new@Base>>,   <<mystack_push@Base>>,
          <<mystack_pop@Base>>  y  similares  encajarian con el primer patron,
          mientras que otros como <<ng_mystack_new@Base>>  no  lo  harian.  El
          segundo  patron  encaja con todos los simbolos con <<private>> en su
          nombre, y las coincidencias heredaran de  este  patron  la  etiqueta
          optional.

       Puede  combinar  los  patrones  listados  anteriormente,  cuando  tenga
       sentido. En tal  caso,  se  procesan  en  el  orden  de  las  etiquetas
       definidas. Por ejemplo, ambos

        (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
        (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0

       encaja     con     <<_ZN3NSA6ClassA7Private11privmethod1Ei@Base>>     y
       <<_ZN3NSA6ClassA7Private11privmethod2Ei@Base>>. Al comparar  el  primer
       patron  se  <<demangle>> el simbolo sin procesar como simbolo C++, para
       despues comparar el nombre <<demangled>> con la expresion regular.  Por
       otra  parte,  al  comparar  el  segundo  patron la expresion regular se
       compara con el nombre sin procesar del simbolo, para despues  confirmar
       si  es  un  simbolo de C++ mediante <<demangle>>. Un fallo de un patron
       basico  lleva  a  un  fallo   de   todo   el   patron.   Por   ejemplo,
       <<__N3NSA6ClassA7Private11privmethod\dEi@Base>> no encajaria con ningun
       patron porque no es un simbolo valido de C++.

       En general, todos los patrones se dividen en dos grupos:  aliases  (los
       basicos   c++   y  symver)  y  patrones  genericos  (regex,  todas  las
       combinaciones de varios patrones basicos). Establecer coincidencias con
       patrones  basados  en  alias es rapido (0(1)) mientras que los patrones
       genericos son 0(N) (N - cuenta generica del patron) para cada  simbolo.
       Debido a ello, se recomienda no abusar de los patrones genericos.

       Los  alias  (primero  c++,  despues  symver) tienen prioridad sobre los
       patrones genericos. Estos se emparejan por orden  de  aparicion  en  la
       plantilla  del  fichero de simbolos hasta el primer resultado de exito.
       Tenga en cuenta, no obstante, que no se  recomienda  la  reorganizacion
       manual  de las entradas en plantillas de fichero ya que dpkg-gensymbols
       genera <<diffs>> basados en el orden alfanumerico de sus nombres.

   Usar <<include>>
       Hay  casos  en  los  que  usar  un  solo   fichero   de   simbolos   es
       contraproducente  cuando  el  conjunto  de  simbolos exportados difiere
       segun la arquitectura. En estos casos, una directiva <<include>>  puede
       ser util de un par de maneras:

       o   Puede factorizar la parte comun en algun fichero externo, e incluir
           ese fichero en su fichero paquete.symbols.arq usando una  directiva
           <<include>> como esta:

           #include "packages.symbols.common"

       o   Al  igual  que  con cualquier simbolo, puede etiquetar la directiva
           <<include>>:

           (tag|..|tagN)#include "file-to-include"

           As a result, all symbols  included  from  file-to-include  will  be
           considered  to  be  tagged with tag .. tagN by default. You can use
           this feature to create a common package.symbols file which includes
           architecture specific symbol files:

             common_symbol1@Base 1.0
            (arch=amd64 ia64 alpha)#include "package.symbols.64bit"
            (arch=!amd64 !ia64 !alpha)#include "package.symbols.32bit"
             common_symbol2@Base 1.0

       Los  ficheros  de  simbolos  se  leen  linea  a linea, y las directivas
       <<include>> se procesan por orden de aparicion. Esto significa  que  el
       contenido  del  fichero  incluido  puede  sustituir cualquier contenido
       aparecido antes de la directiva <<include>>, y  que  todo  contenido  a
       continuacion  de  la  directiva puede sustituir cualquier contenido del
       fichero incluido. Todo simbolo (o incluso otra directiva  <<#include>>)
       en  el  fichero  incluido  puede  especificar  etiquetas adicionales, o
       sustituir valores de las etiquetas heredadas en  la  especificacion  de
       etiqueta.  Por  otra parte, el simbolo no puede eliminar ninguna de las
       etiquetas heredadas.

       Un fichero incluido puede repetir la linea de cabecera que contiene  el
       <<SONAME>>  de la biblioteca. En tal caso, sustituye cualquier linea de
       cabecera leida anteriormente. Por otra  parte,  generalmente  es  mejor
       evitar  duplicar  las  lineas de cabecera. A continuacion puede ver una
       manera de realizar esto:

       #include "libsomething1.symbols.common"
        arch_specific_symbol@Base 1.0

   Buena gesti'on de bibliotecas
       Una   biblioteca   mantenida   adecuadamente   tiene   las   siguientes
       caracteristicas:

       o   su  API  es  estable (los simbolos publicos nunca se eliminan, sino
           que  solo  se  anaden  simbolos  nuevos),  y  los  cambios   pueden
           introducir una incompatibilidad solo cuando el <<SONAME>> cambia;

       o   Idealmente,   usa  el  versionado  de  simbolos  para  alcanzar  la
           estabilidad de la ABI, a pesar de cambios internos y  la  extension
           de la API;

       o   No  exporta simbolos privados (tales como simbolos etiquetados como
           opcionales para evitar un problema).

       Al mantener un fichero <<symbols>> es sencillo  notar  la  aparicion  y
       desaparicion   de   simbolos.   Pero   es  mas  dificil  notar  cambios
       incompatibles en las API y ABI. Por ello, el  responsable  del  paquete
       deberia  leer  cuidadosamente  el  registro  de  cambios  de  la fuente
       original en busca de casos en los que se ha roto la correcta gestion de
       bibliotecas.  Se  deberia  notificar  al  autor  original  en  caso  de
       encontrar problemas  potenciales,  ya  que  un  arreglo  en  la  fuente
       original  del software es siempre preferible a un arreglo especifico de
       Debian.

OPCIONES

       -Pdirectorio-compilaci'on-paquete
              Analiza    directorio-compilaci'on-paquete    en     lugar     de
              <<debian/tmp>>.

       -ppaquete
              Define  el nombre del paquete. Es necesario si aparece mas de un
              paquete binario en <<debian/control>> (o  si  no  existe  ningun
              fichero <<debian/control>>).

       -vversi'on
              Define  la  version  del  paquete.  El  valor  por omision es la
              version extraida de <<debian/changelog>>. Necesario en  caso  de
              una invocacion externa al arbol del paquete fuente.

       -efichero-biblioteca
              Solo  analiza  las bibliotecas listadas explicitamente, en lugar
              de  buscar  todas  las  bibliotecas  publicas.  Puede  usar  una
              expresion  regular  en  fichero-biblioteca para emparejar varias
              bibliotecas con un unico  argumento  (de  otra  forma,  necesita
              varias -e).

       -Inombre-fichero
              Usa nombre-fichero como un fichero de referencia para generar el
              fichero <<symbols>> integrado en el mismo paquete.

       -O     Muestra por la salida estandar el fichero <<symbols>>  generado,
              en lugar de almacenarlo en el arbol de construccion del paquete.

       -Ofichero
              Guarda  el  fichero  de  simbolos  generado  como fichero. Si el
              fichero ya existe su  contenido  se  usara  como  base  para  el
              fichero  <<symbols>>  generado.  Puede  usar esta caracteristica
              para actualizar un fichero <<symbols>> para que coincida con una
              version mas reciente de la biblioteca del autor original.

       -t     Escribe  el  fichero  <<symbols>> en modo plantilla en lugar del
              formato compatible con deb-symbols(5). La diferencia mas notable
              es  que  en modo plantilla los nombres de simbolo y etiquetas se
              escriben en su forma  original,  en  lugar  de  los  nombres  de
              simbolo  post-procesados  con  las  etiquetas eliminadas en modo
              compatible. Ademas, puede que  se  omitan  algunos  simbolos  al
              escribir un fichero estandar de deb-symbols(5) (de acuerdo a las
              reglas de procesamiento de etiquetas), mientras que  siempre  se
              insertan todos los simbolos en el modo plantilla.

       -c[0-4]
              Define  las  comprobaciones  a  realizar  al comparar el fichero
              <<symbols>> generado usando como base el fichero  de  plantilla.
              El  nivel  predefinido  es  1. Aumentar los niveles conlleva mas
              comprobaciones, asi como  la  inclusion  de  todos  los  niveles
              inferiores.  El nivel 0 nunca falla. El nivel 1 falla si algunos
              simbolos  han  desaparecido.  El  nivel  2  falla  si   se   han
              introducido   simbolos   nuevos.   El   nivel  3  falla  si  han
              desaparecido algunas bibliotecas. El nivel 4  falla  si  se  han
              introducido bibliotecas nuevas.

              Puede   sustituir   este   valor  con  la  variable  de  entorno
              <<DPKG_GENSYMBOLS_CHECK_LEVEL>>.

       -q     No muestra informes y nunca genera un <<diff>> entre el  fichero
              <<symbols>> generado y el fichero de plantilla tomado como base,
              ni  muestra  ningun  aviso  relativo  a  bibliotecas  nuevas   o
              ausentes,  o  simbolos  nuevos  o  ausentes.  Esta  opcion  solo
              desactiva la salida  informativa,  pero  no  las  comprobaciones
              (consulte la opcion -c).

       -aarquitectura
              Toma  arquitectura  como  la  arquitectura anfitrion al procesar
              ficheros <<symbols>>. Use esta opcion para  generar  un  fichero
              <<symbols>> o un <<diff>> para cualquier arquitectura, siempre y
              cuando sus binarios ya esten disponibles.

       -d     Activa el modo de depuracion. Se muestran numerosos mensajes que
              explican las acciones de dpkg-gensymbols.

       -V     Activa el modo verboso. El fichero <<symbols>> generado contiene
              simbolos obsoletos en la forma de comentarios. Ademas,  en  modo
              plantilla  los  patrones  de simbolo anteceden a los comentarios
              que listan los simbolos reales que coinciden con el patron.

       -h, --help
              Muestra el modo de uso y termina.

       --version
              Muestra la version y termina.

V'EASE TAMBI'EN

       http://people.redhat.com/drepper/symbol-versioning
       http://people.redhat.com/drepper/goodpractice.pdf
       http://people.redhat.com/drepper/dsohowto.pdf
       deb-symbols(5), dpkg-shlibdeps(1).

AUTORES

       Copyright (C) 2007-2009 Raphael Hertzog

       Esto es software libre; vea la version 2 o  posterior  de  la  Licencia
       Publica General GNU para condiciones de copia. NO hay ninguna garantia.

TRADUCTOR

       Rudy  Godoy  <rudy@kernel-panik.org>,  Ruben  Porras <nahoo@inicia.es>,
       Bruno   Barrera   C.   <bruno.barrera@igloo.cl>,    Carlos    Izquierdo
       <gheesh@ertis.net>,  Esteban  Manchado  y  NOK.   Debian  L10n  Spanish
       <debian-l10n-spanish@lists.debian.org>.
       Revisiones    por    Santiago    Vila     <sanvila@unex.es>,     Javier
       Fernandez-Sanguino, Ruben Porras, Luis Uribe y Omar Campagne.