Pourquoi les développeurs Linux ne peuvent-ils pas créer un format d'emballage universel?

Les sélections de format de package binaire du fournisseur semblent être déterminées par une forme de la loi de Murphy: toutes les distributions que vous n'utilisez pas ont des packages. (Corralary: il n'existe aucune distribution satisfaisant les dépendances de distribution de votre pile logicielle).

Est-ce une question de politique, ou quelque chose de plus profond, que nous n'avons pas vu l'émergence d'un format de package "construire une fois, exécuter n'importe où"?

Il semble approprié de citer Joel Spolsky à ce sujet:

(Soit dit en passant, pour ceux d'entre vous qui suivent le monde mystérieux mais politiquement chargé des formats de flux de syndication de blogs, vous pouvez voir la même chose se produire là-bas. Le RSS est devenu fragmenté avec plusieurs versions différentes, des spécifications inexactes et beaucoup de combats politiques, et la tentative de tout nettoyer en créant un autre format appelé Atom a abouti à plusieurs versions différentes de RSS plus une version d'Atom, des spécifications inexactes et beaucoup de combats politiques. Lorsque vous essayez d'unifier deux forces opposées en créant une troisième alternative, vous vous retrouvez juste avec trois forces opposées. Vous n'avez rien unifié et vous n'avez vraiment rien fixé.)

(pas d'italique dans l'original)

Vous avez (au moins) deux systèmes d'emballage pour Linux. C'est en fait une bonne chose. Un système unique créera simplement un troisième système.

Il y a plusieurs raisons à cela, et un peu d'histoire est pour mettre les choses en perspective.

N'oubliez pas que lorsque nous parlons de «Linux», nous faisons généralement référence à l'une des nombreuses distributions Linux différentes . "Linux" n'est en fait qu'un noyau de système d'exploitation.

L'objectif initial de Linux était de créer un système basé sur Unix qui fonctionnerait sur PC (initialement le 386). La première étape a été de créer le noyau lui-même. Alors que Linus Torvalds travaillait sur le noyau, Richard Stallman travaillait sur son propre système Free Unix, dans le cadre du projet GNU (GNU's Not Unix) . Pour faire court, les deux ont quelque peu convergé parce que GNU avait les utilitaires associés (compilateur C / bibliothèque / outils de construction, shell, éditeurs de texte, etc.) mais pas de noyau pour l'exécuter, et Linux avait le noyau mais pas d'utilitaires pour courir dessus pour le rendre utile pour les masses.

Cette convergence est connue officiellement sous le nom de GNU / Linux. Vous verrez que beaucoup de distributions se réfèrent toujours à elles-mêmes comme des distributions GNU / Linux.

En raison de la nature libre et ouverte de GNU / Linux, n'importe qui pouvait le récupérer et créer un système groupé selon ses goûts spécifiques. Le résultat a été que de nombreux flux différents de méthodes de configuration différentes ont été utilisés pour créer ces systèmes, ce qui a eu pour effet secondaire de créer presque autant de systèmes de gestion de packages différents pour s'adapter à chacun d'eux.

Chaque système complet différent avait ses propres adeptes qui sont restés avec eux au fil des ans, ce qui a abouti à ce que nous avons aujourd'hui: une poignée de systèmes de gestion de packages largement utilisés, profondément enracinés et stables tels que RPM , APT / dpkg et Gentoo's Portage .

Il existe des projets, tels que Autopackage , qui tentent de résoudre le problème, mais l'évolution continue des différents systèmes de gestion de packages pris en charge signifie qu'il existe de nombreuses cibles mobiles à suivre.

Certains éditeurs de logiciels finissent par regrouper les fichiers binaires spécifiques et les copies des dépendances dont ils ont besoin dans un seul grand package qui fonctionnera sur des systèmes spécifiques.

Avoir le même format de package ne serait pas utile de toute façon. Vous ne pouvez tout simplement pas utiliser le même package dans d'autres distributions. Vous ne pouvez même pas souvent l'utiliser dans les différentes versions de la même distribution. Et même la construction du package peut avoir les mêmes problèmes.

Pour installer un package, vous devez respecter les dépendances qui se sont formées lors de la construction du package. Pour construire un package, vous devez respecter les dépendances de construction. Et ces choses changent. Pour pouvoir implémenter les modifications, il est plus facile de prendre en charge uniquement les packages que vous pouvez modifier pour fonctionner après les modifications.

Si toutes les dépendances étaient identiques, ce ne serait pas une distribution différente ou une version différente de la même distribution.

Il y a un peu de "syndrome non inventé ici", je pense. Le système d'empaquetage de Debian est antérieur à RedHat, et pourtant il est supérieur à bien des égards, mais vous ne verrez jamais la commutation de RedHat. Au lieu de cela, vous voyez beaucoup de gens utiliser "apt-rpm" qui essaie de vous donner certains des avantages d'apt avec les fichiers rpm.

Allez juste pour .deb :-)

Il y avait plusieurs formats provisoires, comme l' installation zéro et le conditionnement automatique . Malheureusement, aucun n'a gagné en traction.

Je pense que cletus, Wayne et iny ont assez bien répondu à cette question. J'aimerais vraiment ajouter que ce n'est pas énorme. Je travaille dans un environnement mixte où nous avons Gentoo (portage), SUSE (rpm / zypper) et OpenBSD (packages et ports). L'installation de packages sur l'un d'eux n'est pas difficile, et je ne me soucie pas vraiment du format qu'ils utilisent.

Du point de vue du packaging de logiciels, ce n'est pas non plus trop difficile. Que ce soit Gentoo, une distribution basée sur RPM ou une distribution basée sur deb, cela se résume vraiment à avoir des recettes pour construire le logiciel et ajouter des métadonnées. À condition que le système de construction de ce que vous essayez de compiler ne soit pas totalement fou, il suffit généralement de peu d'écriture d'un script shell glorifié pour créer un package.

Eh bien, il y a toujours des binaires compilés statiquement dans les boules de goudron .... ;-)

Il n'y a pas de définition d'une interface binaire standard pour "Linux" car ce n'est qu'un noyau. Il y a fort à parier que votre pile logicielle devra s'interfacer avec plus que votre noyau, ce qui présente un défi particulier de maintenir un ABI standard entre des centaines d'arbres sources disparates.

Concernant les bons outils de packaging, je préfère Debian GNU / Linux pour son excellent format de packaging binaire. Il a répondu à 90% de mes besoins en outils et applications standard. Les 10% restants sont construits à partir de la source en raison de l'inclusion de composants non libres ou de dépendances de bibliothèque partagée boguées. Lorsque ces applications doivent être déployées, je crée des binaires personnalisés pour les clusters de production.

Pour obtenir une version unique, exécutez n'importe quel format de package sans forcer tout le monde à utiliser la même distribution, vous avez besoin de quelques fonctionnalités importantes:

• Dénomination de package unique au monde, de sorte que deux personnes / distributions ne peuvent pas créer indépendamment des packages différents avec le même nom.

• La possibilité d'installer en parallèle différentes versions de bibliothèques lorsque les packages ont des exigences contradictoires. Une distribution peut décider quelle version de chaque bibliothèque utiliser et forcer tous les packages à utiliser cette version. Un système qui fonctionne sur plusieurs distributions doit être plus flexible.

Zero Install offre ces deux fonctionnalités:

• Les noms sont des URI (par exemple http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Seul le propriétaire d'un domaine peut créer des packages dans cet espace de noms par défaut.

• Chaque version de chaque package va dans son propre répertoire. Chaque application ne voit que les bibliothèques dont elle a besoin, avec les versions avec lesquelles elle est compatible.

Par exemple, l' application Edit dépend de Python <3 comme ceci:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Voir également: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Remarque: je suis un développeur 0install]