Comment et pourquoi créer des packages -dbg, -dev, -doc?

J'écris un package Ubuntu pour un package qui fournit essentiellement un certain nombre de bibliothèques et d'en-têtes qui peuvent ensuite être utilisés pour créer d'autres logiciels. Le paquet se décompose également en sous-paquets plus petits qui sont interdépendants; en ce sens, le package est assez similaire à boost.

J'ai remarqué que des packages comme boost fournissent

[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]

mais rien qui porte le nom boostou libboost.

• Quelle est l'idée derrière cela?
• Quels sont les objectifs du -dbg, -devet des -docforfaits?
• Y a-t-il des instructions sur la façon d'écrire des fichiers de construction pour ces packages?

Idée et objectif

La principale raison de la séparation de ces différents packages est liée à l'espace disque et à la vitesse de téléchargement. En particulier, c'est une grande préoccupation pour l'espace miroir car cela signifie la distribution de plusieurs copies des données. En faisant les foo-common, foo-dataou les foo-docpaquets Architecture: all, nous ne gardons une copie de des données dans l'archive au lieu de l' avoir copié avec chaque architecture (par exemple i386, AMD64, ect ...). La plupart des utilisateurs n'ont pas besoin de symboles de débogage et finissent par rendre le téléchargement du package plus long.

Pour les packages dans les archives officielles d'Ubuntu, il n'y a en fait aucune raison de créer des -dbgpackages manuellement. Les machines de génération suppriment automatiquement les symboles de débogage et les placent dans des -dbgsympackages hébergés sur ddebs.ubuntu.com. (Voir: Paquets de symboles de débogage ) les -dbgpaquets qui existent sont généralement simplement transférés de Debian.

Instructions

Quant à la mise en œuvre, jetez un œil à cette question:

• Comment faire en sorte que le paquetage Debian génère deux paquets avec une archive source en amont?

En bref, de nouvelles strophes doivent être créées debian/controlpour chaque package. Ensuite, les debian/foo-*.installfichiers doivent également être créés. Cela permettra dh_installde mettre le bon contenu dans les bons packages.

Le foo.installpackage binaire principal peut ressembler à ceci:

usr/bin/
usr/lib/

foo-common.install, foo-data.install, foo-doc.installOu que ce soit:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

Et pour foo-dev:

/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so

La création du foo-dbgpackage nécessite une modification, debian/rulescar normalement dh_strip, les symboles de débogage seront supprimés. Nous devons donc remplacer ce comportement:

.PHONY: override_dh_strip
override_dh_strip:
        dh_strip --dbg-package=foo-dbg

• Pour en savoir plus: http://wiki.debian.org/DebugPackage

Boost est un exemple complexe, examinons d'abord un exemple plus simple.

Plus précisément, le paquet source openssl fournit 5 paquets binaires:

• libssl1.0.0contient la bibliothèque dynamique OpenSSL, version 1.0.0. C'est ce que les programmes liés à cette bibliothèque doivent exécuter. Le nom du package contient un numéro de version car vous pouvez avoir d'autres versions de la bibliothèque installées en même temps, si vous avez d'autres programmes liés à une autre version qui n'est pas compatible binaire avec 1.0.0.
• opensslcontient des outils de ligne de commande qui utilisent la bibliothèque OpenSSL. Même si vous disposez de plusieurs versions de la bibliothèque, vous n'avez pas besoin de plusieurs versions de ces outils: il n'y en a qu'un /usr/bin/opensslet les outils, données et documentation associés.
• libssl-devcontient les fichiers dont vous avez besoin si vous souhaitez compiler un programme qui établit un lien avec OpenSSL. Il existe des fichiers d'en-tête C ( *.h), des bibliothèques de liaison ( *.a, *.so) et quelques fichiers assortis.
• libssl-doccontient la documentation de la bibliothèque OpenSSL. Vous n'avez besoin de ce package que si vous allez écrire des programmes qui utilisent la bibliothèque.
• libssl1.0.0-dbgcontient des symboles de débogage. Il n'est utile que pour les personnes qui déboguent la bibliothèque OpenSSL ou les programmes qui l'utilisent. La réponse d'andrewsomething contient plus d'informations sur ces -dbgpackages.

De plus, précis contient une ancienne version de la bibliothèque libssl0.9.8, car il existe des programmes qui sont toujours liés à l'ancienne version.

D'autres packages que vous pourriez voir sont des liaisons pour des langues autres que C. OpenSSL n'est livré avec aucune (il existe des liaisons vers OpenSSL pour d'autres langues, mais elles ne proviennent pas de la même source). Un exemple est sqlite3 , fourni avec les liaisons TCL .

La principale raison de fractionner des packages comme celui-ci est que différents packages ont des publics cibles différents. Un système où personne ne compile jamais n'a besoin que du libpackage principal et peut-être des outils de ligne de commande; ils seront installés automatiquement à partir des dépendances si nécessaire. Si quelqu'un veut compiler un programme qui utilise la bibliothèque, il a besoin du -devpackage. Si quelqu'un veut écrire un programme qui utilise la bibliothèque, il a besoin du -docpackage.

Et Boost? Il suit la même structure, mais comme Boost est une énorme bibliothèque, il est divisé en de nombreux packages plus petits: libboost-*1.46.1et libboost-*1.46-dev. Plus précisément, il n'y a qu'une seule version de Boost, la 1.46 , mais oneiric avait à la fois la 1.42 et la 1.46 . Il existe également un métapaquet boost-defaults qui extrait le package versionné en tant que dépendance.

En regardant libhangul , en plus du package de bibliothèque dynamique libhangul1et du package de développement libhangul-dev, il y a un package libhangul-data. Ce package contient des données supplémentaires requises par la bibliothèque. Même si vous disposez de plusieurs versions de la bibliothèque, elles peuvent partager le -datapackage. De plus, le package est indépendant de l'architecture. Les logiciels contenant une grande quantité de données indépendantes de l'architecture sont divisés en packages dépendants de l'architecture et indépendants de l'architecture, pour économiser de l'espace sur les sites de distribution. Un autre suffixe avec une signification similaire est -common.

Les règles de mise en paquet d'Ubuntu et de Debian sont très similaires, donc le matériel sur la création de paquets Debian s'applique également à Ubuntu. En fait, vous pouvez avoir le même paquet source pour Debian et Ubuntu; la seule chose qui différencie les packages Debian et Ubuntu est de les compiler avec différentes versions de bibliothèquem, et ce n'est pas plus que la différence entre les différentes versions d'Ubuntu. Ayez sous la main la documentation du développeur Debian , en particulier le manuel de politique Debian et la référence du développeur ; voir le Guide du nouveau responsable pour une introduction. Ignorez les parties sur l'utilisation du projet Debian et ainsi de suite, lisez simplement les parties sur la création d'un paquet.dh_make est un bon moyen de commencer avec un paquet deb (vous voudrez sélectionner «Library»).