web-dev-qa-db-fra.com

Comment différents packages peuvent-ils avoir un code source identique?

J'ai récemment appris à quel point il est facile d'obtenir le code source d'un paquet donné à l'aide de apt-get source afin que je puisse obtenir le code source, apporter des modifications et installer ma propre version modifiée de n'importe quel package. C'est bien!

Jusqu'à aujourd'hui, je supposais que chaque paquet aurait son propre code source et que différents paquets auraient un code source différent.

Cependant, maintenant je viens de découvrir que différents packages peuvent avoir un code source identique. Voici un exemple de cela:

Les 4 packages suivants semblent avoir un code source identique:

gir1.2-mutter-4
libmutter-4-0
mutter
mutter-common

Tous les quatre sont installés sur mon ordinateur Ubuntu 19.04. Faire apt-get source gir1.2-mutter-4 donne exactement le même résultat que apt-get source libmutter-4-0, ainsi que pour mutter et mutter-common paquets.

Voici comment je l'ai vérifié:

mkdir a
cd a
apt-get source gir1.2-mutter-4
cd ..
mkdir b
cd b
apt-get source libmutter-4-0
cd ..
diff -r a b

Le diff récursif sur la dernière ligne ci-dessus ne donne aucune sortie, montrant que les répertoires ont un contenu identique.

Maintenant à ma question: Comment différents packages peuvent-ils avoir un code source identique?

En supposant que cela est prévu et non une sorte d'erreur, quelle est la différence entre les packages et comment puis-je voir cette différence?

Se pourrait-il que les packages soient différents dans la façon dont le code source est configuré et compilé, par exemple différentes parties du code sont incluses dans les différents packages? Si oui, où puis-je trouver des informations sur la configuration de chaque package?

Edit: oublié d'ajouter que si vous voulez tester cela, faire apt-get source fonctionne correctement, vous devrez peut-être d'abord l'activer à l'aide de software-properties-gtk comme décrit ici: https://askubuntu.com/a/857433/874649

Edit 2: merci pour les excellentes réponses! J'ai également trouvé cela utile https://askubuntu.com/a/246721/874649 - sur le apt-get build-dep et dpkg-buildpackage commandes très utiles. Après avoir modifié le code source d'un package source, dpkg-buildpackage -us -uc peut être utilisé pour créer de nouveaux fichiers .deb qui peuvent être utilisés pour installer le ou les programmes modifiés.

40
Elias

Vous confondez les packages binaires construits avec le code source/package sous-jacent à partir duquel les packages ont été construits .

Les packages auxquels vous faites référence sont tous construits à partir du même code source/package, mutter. Vous pouvez le trouver facilement en allant à packages.ubuntu.com, en recherchant le package que vous consultez, puis en vous référant au "package source" auquel il se réfère. Qui dans ce cas est mutter:

enter image description here

De là, cependant, nous pouvons vérifier la page Launchpad pour le paquet source de Mutter et voir qu'il construit une multitude de paquets binaires (code source compilé compilé, etc. pour l'installation):

enter image description here

Ces descriptions décrivent ce que chaque package contient/installe. En vous concentrant sur les 4 packages que vous avez indiqués et en utilisant ces descriptions:

  • gir1.2-mutter-4 - Données d'introspection GObject pour Mutter (utilisées par gir et GObject comme bibliothèques/données pour l'interaction Mutter et GObject)
  • libmutter-4-0 - La bibliothèque sous-jacente du gestionnaire de fenêtres Mutter. (Utilisé pour le développement de plugins, le développement et la compilation d'intégrations Mutter, etc. généralement)
  • mutter - le véritable gestionnaire de fenêtres Mutter qui utilise la bibliothèque de gestionnaires de fenêtres de GNOME (c'est pourquoi GObject est nécessaire)
  • mutter-common - Fichiers partagés pour Mutter - généralement des options de configuration par défaut ou des éléments communs à tous les packages construits à partir du package source.

Ce que vous voyez dans votre liste de packages, ce sont les packages intégrés qui proviennent du même code source - chaque package est différents éléments installé après le temps de compilation/compilation et utilisé différemment pour différentes choses. Vous pouvez voir ce qu'il y a dans les packages eux-mêmes en - en téléchargeant les packages individuels, puis y accéder avec p7Zip ou le gestionnaire d'archives intégré dans Ubuntu et voir les différences de ce que chaque package contient de cette façon. Cela dit , ils proviennent tous du même code source - ils contiennent juste différents éléments qui sont installés à le système.

42
Thomas Ward

Les packages source et les packages binaires existent séparément. Chaque package source peut être associé à plusieurs packages binaires. Cela signifie que plusieurs packages binaires peuvent être créés à partir du même package source.

Cela se produit généralement par le biais d'un programme, d'une bibliothèque que le programme utilise pour effectuer une grande partie de son travail, des fichiers d'en-tête utilisés pour le compiler et d'autres programmes (peut-être futurs) qui utilisent cette bibliothèque. Ils sont tous développés et maintenus dans la même arborescence source, qui est utilisée, avec ou sans correctifs Debian ou Ubuntu, pour générer un paquet source. Ensuite, ce package source est utilisé pour créer des packages binaires distincts pour le programme, la bibliothèque et les en-têtes.

C'est ce que vous avez ici (avec d'autres packages binaires également). Vous avez spécifié différents packages binaires dans votre apt source, mais la commande télécharge et décompresse le même package source.

Cela se produit car, lorsque vous passez le nom d'un package à apt source mais il n'y a pas de paquet source avec ce nom, il le traite comme le nom d'un paquet binaire et suppose que vous voulez le paquet source correspondant de ce paquet binaire.


Sur la page principale d'Ubuntu sur Launchpad , vous pouvez rechercher des packages. Launchpad affiche des informations sur les packages source (tandis que buntu Packages Search affiche des informations sur les packages binaires). Si vous recherchez mutter , alors comme l'a dit Thomas Ward vous trouvera la page Launchpad du paquet source mutter dans Ubunt . C'est une bonne façon de voir quels packages binaires correspondent à un package source. En haut de cette page, il est écrit:

paquet de murmure dans Ubuntu

gir1.2-mutter-4: données d'introspection GObject pour Mutter
libmutter-4-0: bibliothèque du gestionnaire de fenêtres du gestionnaire de fenêtres Mutter
libmutter-4-0-dbgsym: Aucun résumé disponible pour libmutter-4-0-dbgsym dans ubuntu eoan.
libmutter-4-dev: Fichiers de développement pour le gestionnaire de fenêtres Mutter
murmure: exemple de gestionnaire de fenêtres utilisant la bibliothèque de gestionnaires de fenêtres de GNOME
mutter-common: fichiers partagés pour le gestionnaire de fenêtres Mutter
mutter-dbgsym: symboles de débogage pour mutter

Même lorsqu'un package binaire n'a pas le même nom que le package source à partir duquel il est construit, vous pouvez généralement trouver ce package source en recherchant sur Launchpad le package binaire.

Vous pouvez souvent savoir quelle est la relation entre un package binaire et le package source utilisé pour le construire en inspectant le nom du package binaire:

  • Les noms de packages binaires commençant par lib fournissent généralement des bibliothèques de code qui peuvent être utilisées par plusieurs programmes (y compris les futurs programmes).

  • Ceux qui se terminent par -dev fournir fichiers d'en-tête , qui facilitent la compilation du code source qui utilise les bibliothèques.

  • Ceux qui se terminent par -dbg ou -dbgsym fournir symboles de débogage (donc même si libmutter-4-0-dbgsym n'affiche pas actuellement de résumé, nous savons qu'il s'agit d'un package de symboles de débogage).

  • Ceux qui se terminent par -common ont tendance à fournir des fichiers, souvent des fichiers de données, qui résident dans /usr/share. Ces fichiers sont parfois du code efficace, juste sous une forme statique et déclarative, mais ils peuvent également fournir des traductions d'interface dans des langues naturelles (c'est-à-dire humaines). Il n'y a pas vraiment de limitation sur ce qui peut être contenu dans un tel package.

    Pour mutter , le -common paquet binaire (dans les versions récentes) contient schémas, raccourcis clavier et documentation. Un avantage de -common packages est que, parce qu'ils ne contiennent généralement pas de code machine natif, le même fichier de package s'applique généralement à toutes les architectures. (Strictement parlant, c'est la seule exigence clé pour les fichiers placés dans /usr/share .)

13
Eliah Kagan

Prenez les ingrédients suivants:

  • Oignons
  • Tomates
  • Pain
  • Olives

Pouvez-vous en faire un seul plat? Non. Ce que vous finissez par manger dépend de la recette.

Chaque paquet contient une recette. Il indique à l'ordinateur ce qu'il faut faire des ingrédients pour produire le ou les plats demandés.

Il est raisonnable et normal que certains emballages partagent une liste d'ingrédients. Bien sûr, dans ce contexte, vous vous attendez à ce que ce ne soit le cas dans la pratique que lorsque lesdits packages proviennent du même projet.