41 votes

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 de n'importe quel package donné en utilisant 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 super !

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

Cependant, j'ai découvert que différents packages peuvent avoir un code source identique. Voici un exemple :

Les 4 packages suivants semblent avoir un code source identique :

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

Les quatre sont installés sur mon ordinateur Ubuntu 19.04. En faisant apt-get source gir1.2-mutter-4, on obtient exactement le même résultat que apt-get source libmutter-4-0, ainsi que pour les packages mutter et mutter-common.

Voici comment j'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

La différence récursive sur la dernière ligne ci-dessus ne donne aucune sortie, montrant que les répertoires ont des contenus identiques.

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

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

Est-il possible que les packages diffèrent dans la manière dont le code source est configuré et compilé, par exemple, différentes parties du code sont incluses dans les différents packages ? Si c'est le cas, où puis-je trouver des informations sur la configuration de chaque package ?

Éditer : j'ai oublié d'ajouter que si vous voulez tester ceci, pour que apt-get source fonctionne correctement, vous devrez peut-être d'abord l'activer en utilisant software-properties-gtk comme décrit ici : https://askubuntu.com/a/857433/874649

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

44voto

Joe the Person Points 5090

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

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

entrer la description de l'image ici

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

entrer la description de l'image ici

Ces descriptions décrivent ce que chaque paquet contient/installé. En se concentrant sur les 4 paquets 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 en tant que bibliothèques/données pour l'interaction de Mutter et GObject)
  • libmutter-4-0 - La bibliothèque sous-jacente pour le gestionnaire de fenêtres Mutter. (Utilisé pour le développement de plug-ins, le développement et la compilation des intégrations Mutter, etc. habituellement)
  • mutter - le véritable gestionnaire de fenêtres Mutter qui utilise la Bibliothèque du gestionnaire de fenêtres 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 paquets construits à partir du paquet source.

Ce que vous voyez dans votre liste de paquets sont les paquets construits qui proviennent du même code source - chaque paquet est composé de différents éléments installés après le temps de construction/compilation et sont utilisés différemment pour différentes choses. Vous pouvez voir ce qui se trouve dans les paquets eux-mêmes en les téléchargeant individuellement et en y accédant avec p7zip ou le Gestionnaire d'archives intégré dans Ubuntu et voir les différences de ce que chaque paquet contient de cette manière. Cela dit, ils proviennent tous du même code source - ils contiennent simplement différents éléments qui sont installés sur le système.

13voto

Eliah Kagan Points 111731

Les paquets sources et les paquets binaires existent séparément. Chaque paquet source peut avoir plusieurs paquets binaires associés. Autrement dit, il est possible de construire plus d'un paquet binaire à partir du même paquet source.

Une des façons courantes que cela se produit est lorsque vous avez un programme, une bibliothèque que le programme utilise pour effectuer une grande partie de son travail, et les 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 entretenus dans le même arborescence source, qui est utilisée, avec ou sans correctifs Debian ou Ubuntu, pour générer un paquet source. Ensuite, ce paquet source est utilisé pour construire des paquets binaires séparés pour le programme, la bibliothèque et les fichiers d'en-tête.

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

Cela se produit parce que, lorsque vous passez un nom de paquet à apt source mais qu'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 à ce paquet binaire.


Sur la page principale d'Ubuntu sur Launchpad, vous pouvez rechercher des paquets. Launchpad affiche des informations sur les paquets sources (alors que la recherche de paquets Ubuntu affiche des informations sur les paquets binaires). Si vous recherchez mutter, alors comme l'a dit Thomas Ward vous trouverez la page Launchpad pour le paquet source mutter dans Ubuntu. C'est une bonne façon de voir quels paquets binaires correspondent à un paquet source. Près du sommet de cette page, il est dit:

Paquet mutter dans Ubuntu

gir1.2-mutter-4 : Données d'introspection GObject pour Mutter
libmutter-4-0 : Bibliothèque de gestionnaires de fenêtres de Mutter
libmutter-4-0-dbgsym : Pas de 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
mutter : Exemple de gestionnaire de fenêtres utilisant la bibliothèque du gestionnaire de fenêtres GNOME
mutter-common : Fichiers partagés pour le gestionnaire de fenêtres Mutter
mutter-dbgsym : Symboles de débogage pour mutter

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

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

  • Les noms de paquets binaires qui commencent par lib fournissent généralement des bibliothèques de code pouvant être utilisées par plusieurs programmes (y compris des programmes futurs).

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

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

  • Ceux qui se terminent par -common fournissent généralement des fichiers, souvent des fichiers de données, résidant dans /usr/share. Ces fichiers sont parfois effectivement du code, mais sous 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 restriction sur ce qui peut aller dans un tel paquet.

    Pour mutter, le paquet binaire -common (dans les versions récentes) contient des schémas, des liaisons de touches et de la documentation. Un avantage des paquets -common est que, puisqu'ils ne contiennent généralement pas de code machine natif, le même fichier de paquet s'applique généralement à toutes les architectures. (Strictement parlant, c'est le seul principal requis pour les fichiers placés dans /usr/share.)

1voto

Prenez les ingrédients suivants :

  • Oignons
  • Tomates
  • Pain
  • Olives

Pouvez-vous faire qu'un seul plat avec ces ingrédients ? Non. Ce que vous finissez par manger dépend de la recette.

Chaque paquet contient une recette. Cela indique à l'ordinateur quoi faire avec les ingrédients, pour produire le(s) plat(s) demandé(s).

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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X