Voici une comparaison des divers formats de paquetages (deb, rpm, tgz, et slp), utilisés par Debian, Red Hat (et autres), Slackware, et une flopée de distributions. J'ai connu quelques aventures avec chacun des formats, lors de construction de paquetages, et plus tard dans mon travail sur les programmes de conversion de paquetages (Alien) étranger. Ce document est une adaptation en français réalisée par A. Adelmar de http://kitenet.net/~joey/pkg-comp.html
J'ai essayé de rendre cette comparaison impartiale mais il faut noter que je suis un fan du format deb, et un développeur Debian. Si vous trouvez n'importe quel partie pris ou inexactitude dans mes comparaisons, ou quelques caractéristiques d'un format de paquetage que j'aurai pu omettre, s'il-vous-plaît veuillez m'adresser un mail pour que je puisse rectifier. Plusieurs personnes ont déjà procédé ainsi. Je cherche aussi des renseignements pour remplir les espaces marqués d'un "?".
Cette comparaison fait seulement référence aux formats
de paquetages et non aux divers outils (dpkg, rpm, etc.) associés.
Qu'est ce
qui est comparé ?
Fait que le format du paquetage peut contenir une signature PGP qui peut être utilisée afin de vérifier l'identité de son créateur
Y-a-t'il un décompte disponible pour tous les fichiers dans ce paquetage?
Y-a-t'il des informations disponibles sur les fichiers de ce paquetage, ainsi que leurs autorisations appropriées, leurs tailles, leurs propriétaires, leurs groupes, un nombre principal et secondaire (major and minor pour les périphériques), etc?
Est-ce que le format du paquetage peut être reconnu par fichier ?
Le paquetage peut-il être décompacté en utilisant des outils standards, sans rencontrer trop de difficulté ? J'ai ajouté la condition que ce ne soit pas difficile car je ne peux pas vous indiquer d'éditer un fichier programme avec vi et de le compiler avec cc pourtant c'est possible pour de décompiler le paquetage, ni même vous suggérer d'écrire une vingtaine de lignes manuscrites sur un interprèteur de commandes qui pourra décompiler le paquetage. Le décompactage doit être manipulable rapidement et doit n'avoir besoin que d'un jeu de commandes simple qui doit se retenir sans difficultés.)
Si le paquetage a certaine sorte de metadonnées (c'est-à-dire, nom du paquetage, description, version) contenu dedans, peut on accéder à ces données par des outils standards, sans trop de difficulté ?
Une dépendance suppose qu'un paquetage a besoin d'autres paquetages pour pouvoir être correctement installé.
Une recommandation vous stipule qu'un paquetage aura presque toujours besoin d'un autre paquetage installé.
Une suggestion vous dira qu'un paquetage peut quelque fois travailler mieux si un autre paquetage est installé. L'utilisateur peut justement être informé de ça comme avec un FYI (For Your Information)...
Un conflit est un paquetage qui ne peut être installé au moment ou un autre est installé. Une raison banale est que les deux paquetages contiennent les mêmes fichiers.
Ceci signifie qu'ils sont ainsi appelés "virtual paquetages", tout comme un navigateur WEB, ou un programme de messagerie, et des paquetages peuvent dire qu'ils subviennent à ces paquets virtuel, jusqu'à ce que d'autres paquets virtuels puissent en dépendre
Un paquetage peut dépendre ou être en confit avec une version spécifique d'un paquetage, ou toutes les version >ou<une version donnée.
Cela signifie qu'un paquetage peut compter sur un paquetage ET (un autre paquetage OU un troisième paquetage).
Ça signifie qu'un paquetage peut requérir que un autre paquetage -quelques autres paquetages - soit installés pour qu'il contienne un fichier donné (tel que /bin/sh) [5].
Les métadonnées des paquetages contiennent des information basique de droits d'auteur. C'est utile pour classer les droits d'auteur automatiquement, etc.
Le paquetage peut être réservé à un groupe (c'est-à-dire, web browser, bibliothèques), lequel permet qu'il soit utilisé par le groupe lors d'une reconnaissance de liste de paquetage valides, etc. Ça le rend plus facile à distribuer avec de larges groupes de paquetages.
Il ce peut qu'il soit attribué une priorité à un paquetage, laquelle résume l'importance de ce paquetage pour le système. Par exemple, Les paquetages de haute priorités pourront être vus prudemment lors d'un mise à jour du système, mais vous pouvez éviter une installation de tout les paquetages de faible priorités et pourtant conscient que vous obtiendrai néanmoins un système fonctionnel.
Les fichiers conf sont ils pris en charge ? Ce sont des fichiers que l'utilisateur en général voudra éditer, aussi quand une nouvelle version du paquetage est installé, le responsable du paquetage sera capable de savoir seul à qui donner les permissions, ou de faire quelque chose de malin style pousser l'utilisateur pour qu'il sache quoi faire si ils ont modifiés les fichiers, ou au moins faire des sauvegardes de changement d'utilisateurs avant de les réécrire. (Peut être ai je besoin de plus de rigueur, ici?)
Ce peut il que les fichiers de documentation soient spécialement marqués? Ceci pouvant être utile pour aider un utilisateur à trouver de la documentation.
Des fichiers fantômes sont des fichiers qui ne sont pas actuellement présent dans le paquetage, mais sont listés comme étant une part de celui-ci dès qu'il est installé. C'est utile pour des fichiers journal (log).
Ce sont des programmes qui contiennent à l'intérieur le paquetage, pour être lancé par le responsable paquetage quand celui ci (paquetage) est installé, ou sitôt installé, ou à un autre moment.
Ces programmes doivent ils êtres écrits, ou peuvent ils compiler du binaires pour être utilisés comme bon?
Un programme pour être lancé par le paquetage manager avant que le paquetage ne soit installé sur le système.
Un programme pour être lancé par le paquetage manager après qu'il soit installé par le système.
Un programme pour être lancé par le paquetage manager avant d'effacer le paquetage
Un programme pour être lancé par le paquetage manager quand les conditions du paquetage installé ont une existences vérifié.
C'est le jeu complet des programmes, qui sont lancés lorsque ce paquetage change d'état, seulement quand l'autre paquetage change d'états.
N'y-a-t'il pas de limite de codage dur dans un format de paquetage, cette puissance le prévient des déploiements rencontré dans le futur nécessiteront ? Par exemple, est ce que les noms des paquetages ou leurs versions auront des tailles sans limites ?
Est il possible que de nouvelle information (text, binary data, whatever) soit ajoutés aux métadonnées facilement, sans changer le format du paquetage?
Ce peut il que l'intégralité de nouvelles section soit ajoutés aux paquetages, sans changer le format des paquetages? Par exemple, est il possible que soit élargi le format des paquetages pour avoir une signature pgp attaché à la fin, ou d'avoir un second jeu de fichiers de données, compilé pour une architecture différente ou avec des optimisations différentes, attaché à la fin? C'est l'ultime test de jusqu'où le format est -il flexible, Je me suis fondamentalement questionné, a t'il été prévu de faire face aux imprévus de nouvelles demandes?
Y-a-t'il un moyen de voir dans le paquetage et de dire quelle version de format le paquetage utilise t'il? Dans des cas extrême, cela signifie, la totalité du format peut être saqué et conçu à nouveau mais de vieux outils seraient ils capable de lire suffisamment des paquetages pour savoir si ils peuvent faire l'affaire.