Comparaison entre les formats de paquetage deb, rpm, tgz et slp.

Publié le par titeuf

 Tableau de comparaison des formats de paquetages.

              Caractéristiques deb rpm tgz slp
              Sécurité, authentification, et vérification
              PGP- paquetages signés non oui non non
              Décompte de fichiers, contrôles oui oui non non
              Autorisations, permissions, propriétaires, etc... oui oui oui oui
              Utilisable par les outils standard Linux
              Reconnaissable par fichier oui oui non non
              Décompactable avec des outils standards oui non oui oui [2]
              Metadonnées accessible avec des outils standards oui non N/A non 
              Réalisable avec des outils standards non [3] non oui non
              Metadonnées
              Dépendances oui oui non oui
              Recommandations oui non non non
              Suggestions oui non non non 
               Conflits oui oui non oui 
               Paquetages virtuels et fournisseurs oui oui non  ?? 
               Dépendances et conflits de versions oui   oui non  ?? 
               Dépendances booléennes complexes oui oui[4] non non 
               Fichiers de dépendances non oui non non 
              Infos droits d’auteur non[6] oui non oui 
              Répartition par groupes oui oui non non 
               Priorités oui non non oui 
               Fichiers particuliers 
               Fichiers config oui oui  non oui 
               Fichiers documentation non oui non non 
               Fichiers fantômes (reliquats) non oui non non 
               Programmes des paquetages 
               Programmes binaires disponibles oui non  ?? oui 
               Programme de pré-installation oui oui non[7] non 
               Programme de post-instalation oui oui oui oui 
               Programme de pré-destruction oui oui non[8] non 
               Programme de vérification non oui non non 
               Déclencheurs (triggers) non oui non non 
               Possibilité d’extension, souplesse (scalability) 
               Pas de limites d’encodage dur oui oui [9] oui non 
               Nouvelles meta-données oui oui[10] N/A non 
               Nouvelle section oui non non non 
               Version de format de données oui oui non oui 

 Qu’est ce qui est comparé ?

Sécurité, authentification et vérification Cette partie traite de l’assurance que vous aurez de savoir qui a créé le paquetage, et de la possibilité de vérifier le paquetage installé sur votre système pour voir si les fichiers qui le composent ont été modifiés depuis que vous l’avez installé.

PGP- paquetages signés 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

Décompte de fichiers (checksums)

Y-a-t’il un décompte disponible pour tous les fichiers dans ce paquetage ?

Permissions, propriétaires, etc.

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 ?

 Utilisable par les outils linux standard.

Convenons qu’il est important parfois d’être capable d’examiner l’intérieur des paquetages sans utiliser leurs outils logiciels spécifiques, cette partie compare comment des paquetage variés peuvent êtres traités avec des outils disponible sur chaque système Linux [1].

Identifiable par fichier

Est-ce que le format du paquetage peut être reconnu par fichier ?

Décompactable par outils standard

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.)

Métadonnées accessible par des outils standards

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é ?

Concevable par des outils standards Est-il possible de créer un paquetage en utilisant des outils standards, sans trop de difficulté ?

 Métadonnées.

Métadonnées est mon terme pour signifier que l’information est contenue sur un paquetage. Cela inclue des choses comme le nom du paquetage, sa description et son numéro de version. Dépendances

Une dépendance suppose qu’un paquetage a besoin d’autres paquetages pour pouvoir être correctement installé.

Recommandations

Une recommandation vous stipule qu’un paquetage aura presque toujours besoin d’un autre paquetage installé.

Suggestions

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)...

Conflits

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.

Virtuel Paquetage et Providers

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

Dépendances et conflits de versions

Un paquetage peut dépendre ou être en confit avec une version spécifique d’un paquetage, ou toutes les version >ou

Dépendance booléenne complexe

Cela signifie qu’un paquetage peut compter sur un paquetage ET (un autre paquetage OU un troisième paquetage).

Fichiers de dépendances

Ç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].

Informations / les droits d’auteur

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.

Répartition par groupe

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.

Priorité

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.

 Fichiers spéciaux.

La capacité à catégoriser des fichiers dépend de ce pour quoi ils sont utilisés, aussi ils peuvent être distribués avec à l’intérieur des caractéristiques spéciales. Fichiers de config

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 ?)

Fichiers documentation

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.

Fichiers fantômes (Ghost file)

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).

 Programmes paquetages.

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.

Programmes binaires autorisés

Ces programmes doivent ils êtres écrits, ou peuvent ils compiler du binaires pour être utilisés comme bon ?

Programme de pré installation

Un programme pour être lancé par le paquetage manager avant que le paquetage ne soit installé sur le système.

Programme de post installation

Un programme pour être lancé par le paquetage manager après qu’il soit installé par le système.

Programme de pré effacement

Un programme pour être lancé par le paquetage manager avant d’effacer le paquetage

Programme de vérification

Un programme pour être lancé par le paquetage manager quand les conditions du paquetage installé ont une existences vérifié.

Déclencheurs (Triggers)

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.

 Malléabilité (Scalability).

Comment un bon format de paquetage est capable de croître pour satisfaire mes futurs besoins. Ceci est très important. Beaucoup de comparaisons au-dessus sont de peu de valeur par rapport à cette partie, parce que de nouveaux programmes de paquetage, des nouveaux champs métadonnées, etc. peuvent être facilement ajouté à un format de paquetage souple.

Pas de limites au codage dur.

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 ?

Nouveau métadonnées

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 ?

Nouvelle partie

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 ?

version de format de données

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.

À faire :

* localisation des paquetages

* support pour le nom principal dans métadonnées, principale ID ( indep) de paquetages

* des multiples versions du même paquetage peuvent être installés simultanément (est ce réellement le bon format de paquetage ?).

* infos disponible pour les programmes paquetage — Les programmes peuvent trouver diverses informations utiles pour prendre des décisions le tant que ça roule. Bien sûr, tous ceux- à sont habilités à voir ce qui figure généralement sur les fichiers système, lancer d’autre programmes et regarder en sortie, etc. Ceci récapitule d’autres informations qui peuvent être profitable. (ancienne version de paquetage, etc... )

Renvois de bas de page.

1.Pourquoi des outils linux standard, et non pas des outils unix en général ? Il eu été démontré en outre que eg, gzip n’est pas sur tous les standards sur tout les systèmes unix en dehors d’ici.

2. en supposant que bunzip2 est un outils standard linux, bien que le paquetage utilise au lieu de cela gzip compression.

3. Bien que un deb n’est juste qu’un fichier ar, il diffère d’un fichier ar voulant implanter quelque petites choses, et ainsi ne peut pas être fait à la main à l’aide de ar.

4. Rpm peut se reposer sur une liste de paquetages, mais le booléen OR n’est pas supporté. Toutefois, le booléen OR peut être émulé en utilisant des paquets virtuel (virtual paquetages and provides). Ce n’est pas tout à fait aussi bon, depuis il faut demander plus de coordination entre paquetagers, mais il laissera passer et dira "oui".

5.Certaine personne considère les fichiers de dépendances comme un amalgame de caractéristiques brumeuses.

6. Les infos sur les droit d’auteur sont incluses dans les paquetages Debian, mais pas d’un format facilement extractible.

7. Supporté par une version de ce format de paquetage utilisé la première fois par SuSE Linux.

8. Supporté par une version de ce format de paquetage utilisé la première fois par SuSE Linux.

9.Techniquement, le rpm "lead" contient des limites d’encodage dur sur le nom du paquetage, mais le (lead) directeur n’est pas longtemps réellement utilisé par quelque chose le fichier mise à part.

10.Pour être profitable, vous aurez besoin de recevoir une étiquette nombre attribué à votre nouveau morceau de métadonnées, lequel impliquera une modification du programme rpm.

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article