Tabla de contenidos
Éstos son algunos consejos e indicaciones sobre aspectos avanzados del mantenimiento de paquetes que pueden ser útiles. Se recomienda encarecidamente que leas todas las referencias sugeridas aquí.
Puede ser necesario editar manualmente los ficheros de las plantillas generadas con la orden dh_make para abordar los temas tratados en este capítulo. La nueva orden debmake maneja mejor estos aspectos de la construcción de paquetes.
Antes de empaquetar bibliotecas compartidas, debes leer atentamente la siguientes referencias básicas:
Éstos son algunos consejos básicos para empezar:
Las bibliotecas compartidas son archivos objeto en formato ELF que contienen código compilado.
Las bibliotecas compartidas se distribuyen como ficheros
*.so
(no como ficheros *.a
o
*.la
).
Las bibliotecas compartidas se utilizan principalmente para compartir código común entre varios ejecutables con la orden ld.
Las bibliotecas compartidas se utilizan, a veces, para proveer varios complementos («plugins») a un ejecutable mediante el procedimiento dlopen.
Las bibliotecas compartidas exportan símbolos que representan objetos compilados como variables, funciones y clases; y permite acceder a ellos desde los ejecutables enlazados.
El SONAME (el nombre lógico) de la biblioteca
compartida
lib
.nombre_biblioteca
.so1
:
objdump -p
lib
[89]
nombre_biblioteca
.so.1
| grep SONAME
El «SONAME» (el nombre lógico) de una biblioteca compartida generalmente coincide con el nombre del archivo de biblioteca (pero no siempre).
El «SONAME» (el nombre lógico) de las bibliotecas compartidas enlazadas a
:
/usr/bin/foo
objdump -p
[90]
/usr/bin/foo
| grep
NEEDED
lib
:
el paquete de biblioteca de la biblioteca compartida
foo
1
lib
con la versión ABI del nombre lógico («SONAME»)
foo
.so.1
1
.[91]
Los guiones de desarrollador de un paquete de biblioteca deben ejecutar ldconfig cuando sea necesario para generar los enlaces simbólicos para el «SONAME» (el nombre lógico).[92]
lib
:
el paquete de símbolos de depuración que contiene los símbolos de depuración
del paquete de la biblioteca compartida foo
1
-dbglib
.
foo
1
lib
: el
paquete de desarrollo que contiene los ficheros de cabeceras y otros de la
biblioteca compartida
foo
-devlib
.[93]
foo
.so.1
En general, los paquetes Debian no deben contener ficheros «Libtool»
*.la
.[94]
En general, en los paquetes Debian no debe utilizarse «RPATH».[95]
Aunque está un poco anticuado y es sólo una referencia secundaria, Debian Library Packaging Guide aún puede ser útil.
Cuando empaquetes bibliotecas compartidas, debes generar el fichero
debian/
para gestionar la versión mínima asociada a cada símbolo para cambios ABI
compatibles con versiones anteriores con el mismo «SONAME» (nombre lógico)
de la biblioteca para el mismo nombre de paquete de biblioteca
compartida.[96] Se aconseja la lectura de
las siguientes referencias básicas:
nombre_del_paquete
.symbols
dh_makeshlibs(1)
dpkg-gensymbols(1)
dpkg-shlibdeps(1)
deb-symbols(5)
Aquí hay un ejemplo para generar el paquete libfoo1
de la versión 1.3
del
autor original con el fichero debian/libfoo1.symbols
adecuado:
Preparar el esqueleto de directorios fuente Debian utilizando el fichero con
las fuentes libfoo-1.3.tar.gz
.
Si es la primera versión del paquete libfoo1
, genera un fichero
debian/libfoo1.symbols
en blanco.
Si la versión anterior del autor (la 1.2
) fue empaquetada
en el paquete libfoo1
con el fichero
debian/libfoo1.symbols
adecuado en el paquete fuente,
utilízalo otra vez.
Si la versión anterior del autor (la 1.2
) no se empaquetó
con el fichero debian/libfoo1.symbols
, genera el
fichero symbols
a partir de todos los paquetes binarios
disponibles con el mismo nombre de paquete de biblioteca compartida que
compartan el mismo «SONAME» (el nombre lógico) de la biblioteca; por ejemplo
las versiones 1.1-1
y
1.2-1
. [98]
$ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1 $ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1 $ : > symbols $ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols $ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols
Ejecuta compilaciones de prueba del árbol de directorios de las fuentes con
órdenes como debuild y pdebuild. Si
fallan debido a símbolos perdidos u otras causas, busca cambios ABI
incompatibles con versiones anteriores que requieran cambios en el nombre
del paquete de biblioteca compartida a algo del tipo libnombrebiblioteca1a
y vuelta a empezar.
$ cd libfoo-1.3 $ debuild ... dpkg-gensymbols: advertencia: hay símbolos nuevos en el fichero de símbolos: ... mire las diferencias a continuación --- debian/libfoo1.symbols (libfoo1_1.3-1_amd64) +++ dpkg-gensymbolsFE5gzx 2012-11-11 02:24:53.609667389 +0900 @@ -127,6 +127,7 @@ foo_get_name@Base 1.1 foo_get_longname@Base 1.2 foo_get_type@Base 1.1 + foo_get_longtype@Base 1.3-1 foo_get_symbol@Base 1.1 foo_get_rank@Base 1.1 foo_new@Base 1.1 ...
Si miras el informe de cambios generado a continuación por la orden
dpkg-gensymbols, lista el fichero
symbols
actualizado adecuadamente para el paquete
binario generado de la biblioteca compartida. [99]
$ cd .. $ dpkg-deb -R libfoo1_1.3_amd64.deb libfoo1-tmp $ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \ >libfoo-1.3/debian/libfoo1.symbols
Compilar paquetes para publicarlos con herramientas como debuild y pdebuild.
$ cd libfoo-1.3 $ debuild clean $ debuild ...
Además de los ejemplos anteriores, también debes comprobar la compatibilidad ABI con más atención y actualizar manualmente las versiones de los símbolos (si es necesario). [100]
Aunque es sólo una referencia secundaria, Debian wiki UsingSymbolsFiles y sus enlaces a otras páginas web puede ser útil.
La función de varias arquitecturas introducida en Debian «wheezy» integra la
instalación en más de una arquitectura de los paquetes binarios (en
particular i386
<->amd64
, pero
también con otras combinaciones) en dpkg
y apt
. Se recomienda leer atentamente las
siguientes referencias:
Ubuntu wiki MultiarchSpec (desarrollador original)
Debian wiki Multiarch/Implementation (Debian)
Se utilizan tripletes del tipo i386-linux-gnu
y
x86_64-linux-gnu
para el directorio de instalación de
bibliotecas compartidas. El triplete de trabajo se establece dinámicamente
al valor $(DEB_HOST_MULTIARCH)
por dpkg-architecture(1) para cada compilación. Por ejemplo, el directorio de
instalación de bibliotecas para varias arquitecturas se cambia como
sigue:[101]
Directorio antiguo | directorio multi-arquitectura i386 | directorio multi-arquitectura amd64 |
---|---|---|
/lib/
|
/lib/i386-linux-gnu/
|
/lib/x86_64-linux-gnu/
|
/usr/lib/
|
/usr/lib/i386-linux-gnu/
|
/usr/lib/x86_64-linux-gnu/
|
Estos son algunos ejemplos típicos de casos posibles de paquetes para varias arquitecturas para los siguientes paquetes:
el código fuente de la biblioteca
lib
foo
-1.tar.gz
el código fuente de una orden
escrito en un
lenguaje compilado
bar
-1.tar.gz
el código fuente de una orden
escrito en un
lenguaje interpretado
baz
-1.tar.gz
Paquete | Arquitectura: | Multi-arquitectura: | Contenido del paquete |
---|---|---|---|
lib
|
any | same | la biblioteca compartida, coinstalable |
lib
|
any | same | los símbolos de depuración de la biblioteca compartida, coinstalable |
lib
|
any | same | los ficheros de cabeceras y otros de una biblioteca compartida, coinstalable |
lib
|
any | foreign | los programas de soporte en tiempo de ejecución no son co-instalables. |
lib
|
all | foreign | los ficheros de documentación de la biblioteca compartida |
|
any | foreign | los ficheros compilados del programa, no son coinstalables |
|
all | foreign | los ficheros de documentación del programa |
|
all | foreign | los ficheros de programa interpretados |
Hay que tener en cuenta que el paquete de desarrollo debe contener un enlace
simbólico a la biblioteca compartida asociada sin el
número de versión. P. ej.:
/usr/lib/x86_64-linux-gnu/libfoo.so
->
libfoo.so.1
Puedes construir un paquete de biblioteca Debian con la opción multi-arquitectura activada utilizando dh(1) como sigue:
Actualizar debian/control
.
Añadir Build-Depends: debhelper (>=9)
en la sección del
paquete fuente.
Añadir Pre-Depends: ${misc:Pre-Depends}
por cada paquete
binario de biblioteca compartida.
Añadir el campo Multi-Arch:
en cada sección de paquete
binario.
Establecer debian/compat
a « 9 ».
Cambiar el directorio habitual /usr/lib/
por el
directorio multi-arquitectura
/usr/lib/$(DEB_HOST_MULTIARCH)/
para todos los guiones de
empaquetado.
Añadir (primero) DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture
-qDEB_HOST_MULTIARCH)
en debian/rules
para
establecer la variable DEB_HOST_MULTIARCH
.
Reemplazar /usr/lib/
por
/usr/lib/$(DEB_HOST_MULTIARCH)/
en
debian/rules
.
Si se utiliza ./configure
como parte del objetivo
override_dh_auto_configure
en el fichero
debian/rules
, hay que reemplazarlo por
dh_auto_configure --
. [102]
Cambiar todas referencias a /usr/lib/
por
/usr/lib/*/
en los ficheros
debian/
nombre_del_paquete
.install
Generar ficheros como
debian/
desde
nombre_del_paquete
.linksdebian/
dinámicamente añadiendo un guión al objetivo
nombre_del_paquete
.links.inoverride_dh_auto_configure
en
debian/rules
.
override_dh_auto_configure: dh_auto_configure sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \ debian/nombre_del_paquete
.links.in > debian/nombre_del_paquete
.links
Debes comprobar que el paquete de biblioteca compartida solo contiene los ficheros esperados y que el paquete «-dev» sigue funcionando correctamente.
Todos los ficheros instalados simultáneamente por el paquete multi-arquitectura en el mismo directorio deben contener los mismos ficheros. Debes tener cuidado en las diferencias generadas por el orden de los bits de datos y por el algoritmo de compresión.
Si un paquete se mantiene exclusivamente para Debian o para uso local, su
paquete fuente puede contener todos los ficheros
debian/*
. Hay dos maneras para empaquetarlos.
Puedes excluir los ficheros de debian/*
al generar el
fichero comprimido con los ficheros fuente y construir el paquete como un
paquete Debian no nativo como se explica en Sección 2.1, “Plan de trabajo para la construcción de paquetes Debian”.
Algunas personas animan a utilizar este esquema de trabajo.
La alternativa es el esquema de trabajo para paquetes nativos Debian.
Generaremos un paquete fuente Debian en el formato 3.0
(native)
, utilizando un archivo comprimido en formato «tar» que
incluirá todos los archivos.
nombre_del_paquete
_versión
.tar.gz
nombre_del_paquete
_versión
.dsc
Construiremos un paquete binario Debian del paquete de fuentes nativo Debian.
nombre_del_paquete
_versión
_arquitectura
.deb
Por ejemplo, si los ficheros fuente están en
~/mi_paquete-1.0
sin los ficheros del directorio
debian/*
, puedes construir un paquete Debian nativo
ejecutando la orden dh_make como sigue:
$ cd ~/mi_paquete-1.0 $ dh_make --native
Entonces el directorio debian
y su contenido son
generados como en Sección 2.8, “Paquete no nativo Debian inicial”. De esta manera no se
genera un archivo «tarball» ya que este es un paquete Debian nativo. Pero
esa es la única diferencia. El resto de las actividades de empaquetado son
prácticamente las mismas.
Después de la ejecución de la orden dpkg-buildpackage, encontrarás los siguientes ficheros en el directorio superior:
mi_paquete_1.0.tar.gz
Este es el archivo del código fuente generado a partir del directorio
mi_paquete-1.0
por la orden
dpkg-source (su sufijo no es
orig.tar.gz
.).
mi_paquete_1.0.dsc
Este es el sumario del contenido del código fuente en el caso de los paquetes Debian no nativos (no tiene código de revisión Debian).
mi_paquete_1.0_i386.deb
Este es el paquete binario completo en el caso de los paquetes Debian no nativos (no tiene código de revisión Debian).
mi_paquete_1.0_i386.changes
Este archivo describe todos los cambios realizados en el versión actual del paquete en el caso de los paquetes Debian no nativos (no tiene código de revisión Debian).
[89]
Como alternativa: readelf -d
lib
nombre_biblioteca
.so.1
| grep SONAME
[90]
Como alternativa: readelf -d
lib
foo
.so.1
| grep
NEEDED
[93] Consulta Debian Policy Manual, 8.3 "Static libraries" y Debian Policy Manual, 8.4 "Development files".
[94] Consulta Debian wiki ReleaseGoals/LAFileRemoval.
[95] Consulta Debian wiki RpathIssue.
[96] Los cambios ABI incompatibles con versiones anteriores, normalmente requieren actualizar el «SONAME» (el nombre lógico) de la biblioteca y el de la biblioteca compartida a otros nuevos.
[97] Para bibliotecas C++ y otros casos en los que el seguimiento individual de símbolos es difícil, es mejor consultar Debian Policy Manual, 8.6.4 "The shlibs system".
[98]
Las versiones previas de los paquetes Debian están disponibles en http://snapshot.debian.org/. La revisión Debian del
paquete sigue a la versión para facilitar mantenimiento de versiones
anteriores («backport») del paquete: 1.1
<<
1.1-1~bpo70+1
<< 1.1-1
y
1.2
<< 1.2-1~bpo70+1
<<
1.2-1
[99]
La revisión de Debian se deriva de la versión para hacer más fácil el
mantenimiento de versiones anteriores («backport») del paquete:
1.3
<< 1.3-1~bpo70+1
<<
1.3-1
[101] Viejas ubicaciones especiales para bibliotecas como
/lib32/
y /lib64/
ya no se
utilizaran más.
[102]
Como alternativa, puedes añadir los argumentos
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
y
--libexecdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
en
./configure
. Fíjate que --libexecdir
especifica el directorio predeterminado para la instalación de programas
ejecutables que son ejecutados por otros programas en lugar de por los
usuarios. El valor predeterminado por «Autotools» es
/usr/libexec/
pero en Debian es
/usr/lib/
.