Annexe A. Empaquetage avancé
Précédent     

Annexe A. Empaquetage avancé

Table des matières

A.1. Bibliothèques partagées
A.2. Gestion de debian/paquet.symbols
A.3. Multiarchitecture
A.4. Construction d'un paquet de bibliothèque partagée
A.5. Paquet Debian natif

Here are some hints and pointers for advanced packaging topics that you are most likely to deal with. You are strongly advised to read all the references suggested here.

Vous pouvez avoir besoin d’éditer vous-mêmes les fichiers de modèle d’empaquetage produits par la commande dh_make pour répondre à des préoccupations de ce chapitre. La nouvelle commande debmake devrait le faire de meilleure façon.

A.1. Bibliothèques partagées

Avant d'empaqueter des bibliothèques partagées, vous devriez lire les références essentielles suivantes avec attention :

Voici quelques conseils simplifiés à l'extrême pour commencer :

  • les bibliothèques partagées sont des fichiers objet ELF contenant du code compilé ;

  • les bibliothèques partagées sont distribuées en fichiers *.so (pas en fichiers *.a ni en fichiers *.la) ;

  • les bibliothèques partagées sont surtout utilisées pour partager du code commun à plusieurs exécutables avec le mécanisme ld ;

  • les bibliothèques partagées sont parfois utilisées pour fournir plusieurs greffons à un exécutable avec le mécanisme dlopen ;

  • Shared libraries export symbols, which represent compiled objects such as variables, functions, and classes; and enable access to them from the linked executables.

  • le SONAME d'une bibliothèque partagée libtruc.so.1 : objdump -p libtruc.so.1 | grep SONAME ;[88]

  • le SONAME d'une bibliothèque partagée correspond normalement au nom du fichier de bibliothèque (mais pas toujours) ;

  • le SONAME d'une bibliothèque partagée liée à /usr/bin/truc : objdump -p /usr/bin/truc | grep NEEDED ;[89]

  • libtruc1 : le paquet de bibliothèque pour la bibliothèque partagée libtruc.so.1 avec la version d'ABI SONAME 1 ;[90]

  • les scripts du responsable du paquet de bibliothèque doivent appeler ldconfig dans des circonstances particulières pour créer les liens symboliques nécessaires au SONAME ;[91]

  • libfoo1-dbg: the debugging symbols package that contains the debugging symbols for the shared library package libfoo1.

  • libfoo-dev: the development package that contains the header files etc. for the shared library libfoo.so.1.[92]

  • Debian packages should not contain *.la Libtool archive files in general.[93]

  • Debian packages should not use RPATH in general.[94]

  • bien qu'il soit dépassé et que ce ne soit qu'une référence secondaire, le guide d'empaquetage de bibliothèques Debian peut encore être utile.

A.2. Gestion de debian/paquet.symbols

When you package a shared library, you should create a debian/package.symbols file to manage the minimal version associated with each symbol for backward-compatible ABI changes under the same SONAME of the library for the same shared library package name.[95] You should read the following primary references in detail:

Here is a rough example of how to create the libfoo1 package from the upstream version 1.3 with the proper debian/libfoo1.symbols file:

  • préparer le squelette d'arborescence source Debian en utilisant le fichier amont libtruc-1.3.tar.gz :

    • s'il s'agit du premier empaquetage du paquet libtruc1, créer le fichier vide debian/libtruc1.symbols ;

    • si la version amont précédente 1.2 a été empaquetée en tant que paquet libtruc1 contenant le fichier debian/libtruc1.symbols adéquat dans son paquet source, le réutiliser ;

    • If the previous upstream version 1.2 was not packaged with debian/libfoo1.symbols, create it as the symbols file from all available binary packages of the same shared library package name containing the same SONAME of the library, for example, versions 1.1-1 and 1.2-1. [97] 

      $ dpkg-deb -x libtruc1_1.1-1.deb libtruc1_1.1-1
$ dpkg-deb -x libtruc1_1.2-1.deb libtruc1_1.2-1
$ : > symbols
$ dpkg-gensymbols -v1.1 -plibtruc1 -Plibtruc1_1.1-1 -Osymbols
$ dpkg-gensymbols -v1.2 -plibtruc1 -Plibtruc1_1.2-1 -Osymbols

  • Make trial builds of the source tree with tools such as debuild and pdebuild. (If this fails due to missing symbols etc., there were some backward-incompatible ABI changes that require you to bump the shared library package name to something like libfoo1a and you should start over again.) 

    $ cd libtruc-1.3
$ debuild
...
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ...
 see diff output below
--- debian/libtruc1.symbols (libtruc1_1.3-1_amd64)
+++ dpkg-gensymbolsFE5gzx        2012-11-11 02:24:53.609667389 +0900
@@ -127,6 +127,7 @@
  truc_get_name@Base 1.1
  truc_get_longname@Base 1.2
  truc_get_type@Base 1.1
+ truc_get_longtype@Base 1.3-1
  truc_get_symbol@Base 1.1
  truc_get_rank@Base 1.1
  truc_new@Base 1.1
...

  • If you see the diff printed by the dpkg-gensymbols as above, extract the proper updated symbols file from the generated binary package of the shared library. [98] 

    $ cd ..
$ dpkg-deb -R  libtruc1_1.3_amd64.deb libtruc1-tmp
$ sed -e 's/1\.3-1/1\.3/' libtruc1-tmp/DEBIAN/symbols \
        >libtruc-1.3/debian/libtruc1.symbols

  • construire les paquets pour la publication avec des outils comme debuild et pdebuild : 

    $ cd libtruc-1.3
$ debuild clean
$ debuild
...

En plus des exemples précédents, il faut vérifier plus profondément la compatibilité d'ABI et changer vous-même les versions de certains symboles si nécessaire. [99]

Bien que ce ne soit qu'une référence secondaire, le wiki Debian sur l'utilisation de fichiers symboles et les pages web qui y sont liées peuvent être utiles.

A.3. Multiarchitecture

La fonctionnalité de multiarchitecture introduite dans Debian Wheezy intègre la prise en charge pour l'installation interarchitecture de paquets binaires (en particulier entre i386 et amd64, mais aussi d'autres combinaisons) dans dpkg et apt. Vous devriez lire les références suivantes avec attention :

Cela utilise le triplet du style i386-linux-gnu et x86_64-linux-gnu pour le chemin d'installation des bibliothèques partagées. Le chemin de triplet réel est défini dynamiquement dans la variable $(DEB_HOST_MULTIARCH) par la commande dpkg-architecture(1) pour chaque construction de paquet binaire. Par exemple, le chemin d'installation de bibliothèques multiarchitectures est modifié comme suit :[100]

Ancien chemin Chemin multiarchitecture i386 Chemin multiarchitecture amd64
/lib/ /lib/i386-linux-gnu/ /lib/x86_64-linux-gnu/
/usr/lib/ /usr/lib/i386-linux-gnu/ /usr/lib/x86_64-linux-gnu/

Here are some typical multiarch package split scenario examples for the following:

  • une bibliothèque source libtruc-1.tar.gz ;

  • un outil source bidule-1.tar.gz écrit en langage compilé ;

  • un outil source machin-tar.gz écrit en langage interprété :

Paquet Architecture Multi-Arch Contenu du paquet
libtruc1 any same la bibliothèque partagée, co-installable
libtruc1-dbg any same les symboles de débogage de bibliothèque partagée, co-installable
libtruc-dev any same les fichiers d'en-tête, etc. de bibliothèque partagée, co-installable
libtruc-tools any foreign les programmes de prise en charge en cours d'exécution, non co-installable
libtruc-doc all foreign les fichiers de documentation de bibliothèque partagée
bidule any foreign les fichiers du programme compilé, non co-installable
bidule-doc all foreign les fichiers de documentation du programme
machin all foreign les fichiers du programme interprété

Veuillez remarquer que le paquet de développement devrait contenir un lien symbolique vers la bibliothèque partagée associée sans numéro de version. Par exemple : /usr/lib/x86_64-linux-gnu/libtruc.so → libtruc.so.1.

A.4. Construction d'un paquet de bibliothèque partagée

You can build a Debian library package enabling multiarch support using dh(1) as follows:

Veuillez vous assurer d'avoir vérifié que le paquet de bibliothèque partagée ne contient que les fichiers attendus, et que le paquet -dev fonctionne toujours.

All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful of differences generated by the data byte order and by the compression algorithm.

A.5. Paquet Debian natif

Si un paquet est maintenu uniquement pour Debian ou simplement pour un usage local, ses sources peuvent contenir tous les fichiers debian/*. Il existe deux façons de l’empaqueter.

You can make the upstream tarball by excluding the debian/* files and package it as a non-native Debian package as in Section 2.1, « Processus de construction de paquet Debian ». This is the normal way, which some people encourage using.

L’autre méthode est d’utiliser la manière de procéder pour un paquet Debian natif.

  • créer le paquet source Debian natif au format 3.0 (native) en utilisant un seul fichier tar compressé où tous les fichiers sont intégrés :

    • paquet_version.tar.gz
    • paquet_version.dsc

  • construire les paquets binaires Debian à partir du paquet source Debian natif :

    • paquet_version_arch.deb

For example, if you have source files in ~/mypackage-1.0 without the debian/* files, you can create a native Debian package by issuing the dh_make command as follows: 

$ cd ~/monpaquet-1.0
$ dh_make --native

Then the debian directory and its contents are created just like in Section 2.8, « Paquet Debian non natif initial ». This does not create a tarball, since this is a native Debian package. But that is the only difference. The rest of the packaging activities are practically the same.

Après exécution de la commande dpkg-buildpackage, les fichiers suivants apparaîtront dans le répertoire parent :

  • monpaquet_1.0.tar.gz

    c'est l'archive compressée du code source créé à partir du répertoire monpaquet-1.0 par la commande dpkg-source (il ne se termine pas par orig.tar.gz) ;

  • monpaquet_1.0.dsc

    This is a summary of the contents of the source code, as in the non-native Debian package. (There is no Debian revision.)

  • monpaquet_1.0_i386.deb

    This is your completed binary package, as in the non-native Debian package. (There is no Debian revision.)

  • monpaquet_1.0_i386.changes

    ce fichier décrit toutes les modifications effectuées dans la version actuelle du paquet comme dans un paquet Debian non natif (il n'y a pas de révision Debian).


[88] Alternative : readelf -d libtruc.so.1 | grep SONAME.

[89] Alternative : readelf -d libtruc.so.1 | grep NEEDED.

[95] Les modifications d'ABI non rétrocompatibles devraient normalement nécessiter une mise à jour du SONAME de la bibliothèque et du nom de paquet de la bibliothèque partagée.

[96] Pour les bibliothèques C++ et d'autres cas lorsque le suivi de symboles individuels est trop compliqué, suivez plutôt la Charte Debian, 8.6.4 « Le système de shlibs ».

[97] Toutes les versions précédentes des paquets Debian sont disponibles sur http://snapshot.debian.org/. La révision Debian est supprimée de la version pour faciliter le rétroportage du paquet : 1.1 << 1.1-1~bpo70+1 << 1.1-1 et 1.2 << 1.2-1~bpo70+1 << 1.2-1

[98] La révision Debian est supprimée de la version pour faciliter le rétroportage du paquet : 1.1 << 1.3 << 1.3-1~bpo70+1 << 1.3-1

[100] Old special purpose library paths such as /lib32/ and /lib64/ are not used anymore.

[101] Sinon, les arguments --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) et --libexecdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) peuvent être ajoutés à ./configure. Veuillez remarquer que --libexecdir indique le chemin par défaut pour installer les programmes exécutables démarrés par d'autres programmes plutôt que par des utilisateurs. Sa valeur Autotools par défaut est /usr/libexec/ mais sa valeur Debian par défaut est /usr/lib/.

Précédent     
Chapitre 9. Envoi de paquet  Sommaire