Provided by: dpkg-dev_1.16.0.3ubuntu5_all bug

NOMBRE

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

SINOPSIS

       dpkg-gensymbols [opciones]

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.

   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>>:

           (etiqueta|..|etiquetaN)#include "fichero-para-include"

           Como  resultado, se considerara que todos los simbolos incluidos en
           fichero-para-include estan etiquetados con  etiqueta  ..  etiquetaN
           por  omision.  Puede usar esta caracteristica para crear un fichero
           comun package.symbols, que incluye ficheros de simbolos especificos
           a la arquitectura.

             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.