Sous GNU/Linux, l'installation est simple comme une requête car le point de différence fondamental avec Windows, c'est que c'est un système indépendant qui est responsable de l'installation et pas l'auteur de l'application elle-même.
Les paquets, comment ça marche ?
Il existe de nombreux systèmes de gestion de paquets sous Linux mais ils partagent tous les caractéristiques suivantes :
- Un processus d'installation indépendant de l'application installée - C'est un peu l'aspect fondamental de toutes les gestions de paquets. Une application installée ne sait ainsi jamais par qui et par quoi elle sera mise en place dans le système. Contrairement à ce qui se passe couramment sous Windows, ce n'est donc jamais elle qui gère son installation et sa désinstallation.
- Le paquet - C'est l'unité de base de l'installation. Il s'agit d'un fichier (.rpm, .deb, etc) qui contient les divers éléments à installer, une description, un nom, une version, une liste des changements, et surtout une liste des autres paquets (nom et version) dont il dépend.
- La base de donnée locale - Elle contient la liste de TOUS les paquets installés. Cet aspect peut faire penser à l'Ajouter/Supprimer de Windows à la nuance près qu'il est beaucoup plus efficace, car il garde la trace non seulement des applications haut-niveau (ex. OpenOffice v2.2), mais aussi de toutes les librairies et de leurs versions respectives. C'est un composant vital et extrêmement précieux qui permet jusqu'à de savoir de quel paquet provient un fichier sur le système et s'il a par exemple été modifié depuis son installation. Cette base facilite et fiabilise grandement la processus de désinstallation.
- Un utilitaire de gestion locale des paquets - Il chargé de l'installation et désinstallation d'un paquet ainsi que du maintien et de l'interrogation de la base de donnée. Selon les distributions, cet utilitaire est yum (RedHat/Fedora), apt (Debian), rpm (RedHat, Mandriva), etc.
- Un dépôt - Les dépôts sont des dossiers au sens large du terme (locaux, ftp, http, etc.) contenant des paquets prêt à être installés. Les dépôts sont généralement spécifiques à une distribution et même à une version de distribution. D'une distribution à l'autre ils peuvent être plus ou moins vastes et plus ou moins nombreux. Pour Mandriva, cela représente pas moins d'une vingtaine de dépôts (environ 34Go), disponibles sur internet où l'on trouve à peu près tout d'OpenOffice à FireFox en passant par Gimp. Tout cela directement accessible sans avoir à lancer Google...
- Un utilitaire de gestion dépendances entre les paquets - cet outil va ainsi avoir une vision globale de la base de donnée locale des paquets installés mais aussi des paquets disponibles dans les dépôts locaux ou sur internet. C'est lui qui va ainsi être capable lors de l'installation d'une application, sur la base des informations de dépendance renvoyées par l'utilitaire de gestion locale des paquets, d'aller chercher les paquets manquants. Il s'agit par exemple de yum, urpmi, etc. .
- Un frontal graphique - Il s'agit d'une application graphique qui va rendre tout cela plus visuel. Il peut cumuler les deux précédents rôles ou simplement utiliser les précédents utilitaires. Il s'agit par exemple de Synaptic, rpmdrake, etc... Certains de ces frontaux, comme smart, sont capable d'utiliser des paquets provenant de plusieurs systèmes (.deb, .rpm).
Pour le reste de ce billet, nous allons nous concentrer spécifiquement sur le système de paquets .rpm, avec l'utilitaire de gestion locale rpm et de dépendances urpmi.
Ajouts de dépôts dans URPMI
Pour rendre tout cela plus parlant, imaginons que nous partions de rien, d'une installation standard, et que nous voulions installer openOffice à partir d'internet sur une Mandriva. Mandriva utilise le système de paquet hérité de la RedHat : rpm. D'ailleurs au passage, techniquement Mandriva est une RedHat, du moins à l'origine, comme Ubuntu est une Debian.
L'utilitaire bas niveau de gestion des paquets RPM est la commande rpm. La base de données locale utilise est la petite SGBD BerkleyDB. L'utilitaire qui gère les dépôts et les dépendances entre paquets est urpmi.
L'utilitaire urpmi utilise donc en interne l'utilitaire rpm qui lui utilise des paquets RedHat au format .rpm. Pour Urpmi, un dépôt s'appelle un média. Ce média peut être un dossier local, un DVD à insérer, un site FTP, une page HTML, etc... Lorsque vous venez d'installer Mandriva, les seuls médias connus d'urpmi sont les 3 CD, ou le DVD, d'installation. Nous allons changer cela, et lui donner un plus vaste choix de logiciel via internet.
Le plus simple est d'utiliser l'excellent site easyUrpmi (je continue à préférer l'ancienne interface). Vous sélectionnez alors la version de Mandriva que vous utilisez et vous pressez process Step 2. Une liste de dépôt disponibles apparaît. Petite explication sur ces dépôts et leur rôle.
Les dépôts, ou médias, pour Mandriva
Mandriva a fortement normalisé la structure de ses dépôts depuis quelques années. Aujourd'hui chaque dépôt peut avoir 4 parfums différent : release, updates, backports et testing.
Le dépôt "release" est celui qui contient les paquets qui ont été livrés au moment où la distribution est sortie. Le dépôt "updates", comme son nom l'indique, est le dépôt des mises à jour du dépôt "release". Le dépôt "backports" contient des versions pas toujours stables mais beaucoup plus récentes, qui feront généralement parti de la prochaine version de Mandriva. Enfin le dépôt "testing" est en quelque sorte le pre-backports.
Cela veut dire que si vous êtes en train de régler un serveur de production, vous allez éviterez backports et testing. En revanche, pour tester et s'amuser, c'est une vraie mine d'or réglant pas mal d'aigreurs de mandriviens qui n'avaient droit à de nouvelles version qu'à chaque release de Mandriva.
Maintenant que nous connaissons les parfums, regardons les dépôts existants. Il y a déjà "main", c'est le dépôt officiel de Mandriva qui contient plus ou moins tout ce qu'il y a déjà dans le DVD d'installation.
Il y a ensuite le très volumineux "contrib". Comme son nom l'indique, il s'agit du dépôt des contributeurs à Mandriva. Il n'est pas officiellement supporté par Mandriva mais presque. Ce dépôt est simplement vitale et complète parfaitement le dépôt principale pour fournir à peu près tout ce qui peut exister comme application libre.
Ensuite nous avons le fameux PLF et le plus récent "non-free". Pour commencer par le plus simple "non-free" est comme son nom l'indique un dépôt de ce qui ne peut pas être mis dans une distribution considérée comme libre mais sans pour autant que ce qu'il contient puisse donner lieu à un procès. Il s'agit généralement de pilotes et de firmwares propriétaires (sources fermés) ou aux licences incompatibles avec la GPL et que l'éditeur veut bien voir distribué par d'autres que lui. C'est par exemple là que se trouvent les pilotes nVidia.
Avec les dépôt "plf-nonfree" c'est un peu plus "obscure". Vous trouverez là les codecs de Microsoft, les fontes de Windows, l'émulation d'une PlayStation, etc... En bref des choses qui sont non seulement non-libre mais aussi relativement problématiques d'un point de vue légal. Pour bien situer le débat, PLF veut dire Pingouin Liberation Front !
Mais n'espérez cependant pas y échapper car ce dépôt est lui aussi vital. Car sans lui comment lire ces maudites vidéos WMF ? Et même comment lire aussi... un simple DVD ?
Il existe encore bien d'autres dépôts pour Mandriva hors ceux cités par easyUrpmi. KDE.org fournit des dépôts pour ses versions les plus récentes. Le site Seer Of Soul (SoS) fournit lui aussi des versions plus récentes de Gnome, Kde, etc... Mais commençons déjà avec les dépôts easyUrpmi.
Maintenant que vous savez tout cela, retours sur le choix des médias dans easyurpmi.zarb.org où vous n'avez plus qu'à... tout sélectionner 
Sauf bien sur si vous êtes en train de monter un serveur... Ensuite vous pouvez choisir le site où se connecter pour récupérer les dépôts. Choisissez un serveur en France et rapide (ex. proxad, free, club-internet). Ensuite pressez proceed step 3.
Là s'affiche la liste des commandes à exécuter dans une console, en root, pour récupérer toutes ces bonnes choses. Avant de vous lancer, vous devez vider la liste des médias existant sur votre machine puis coller brutalement la liste des commande fournit par le site :
Une autre solution intéressante pour mettre en place les dépôts sur une machine à partir d'une autre machine qui les a correctement réglés est la commande --dump-config d'urmpq qui liste les médias sous une forme exploitable par urpmi.addmedia :
Recherche dans les dépôts
L'autre aspect pour le peu génial de la gestion par paquets des installations est la recherche. Avec urpmi la commande de recherche s'appelle urpmq. Les options sont riches mais voici quelques utilisations "standard".
Installation d'un paquet
Lorsque nous avons trouvé ce que nous voulons, nous pouvons l'installer :
C'est aussi simple que cela... Les Windowsiens apprécieront même si j'ai entendu dire qu'un projet de ce genre se lançait sur cette plate-forme.
Techniquement il serait possible de complètement se passer d'urpmi et de gérer tout avec rpm, mais cela implique de gérer toutes les dépendances à la main, ce qui n'est pas très amusant. Imaginez qu'à chaque appel à rpm -i (-i pour "installer"), il faille 1/ fournit la bonne URL vers le paquet et 2/ l'entendre couiner qu'il n'a pas la librairie bidulo-atomique-1234.rpm et qu'il vous faille chercher l'URL de cette librairie, lancer un rpm -i dessus, entendre le zinzin couiner qu'il manque une dépendance libatom-machin-1234.rpm, et ainsi de suite jusqu'à ce que mort s'en suive... Il faut l'avoir vécu au moins une fois pour bien comprendre l'apport du gestionnaire de dépendances et de dépôts...
urpmi peut aussi être utilisé pour installer automatiquement des mises à jours.
Maintenant nous savons installer, comment faire pour remplacer à neuf un paquet qui a été torpillé par exemple par une compilation malheureuse ? Et bien cela se fait très simplement avec l'option --replacepkg:
Travail sur la base de donnée locale
Maintenant que notre paquet est installé, avec toutes ses dépendances, nous rentrons dans le domaine de l'utilitaire de gestion locale des paquets, rpm, et de sa base de donnée. En effet chaque appel à urpmi a généré une série d'appel à rpm -i qui a chaque fois a ajouté à la base de données locales les versions installées, les noms de librairies, tous les fichiers ajoutés, etc..
Sachant ceci, il est possible de faire plein de choses intéressantes avec cette base de donnée locale.
Désinstallation
Pour supprimer une application, c'est aussi simple que ça :
urpme fonctionne comme urpmi, c'est à dire qu'il va chercher à vérifier que l'on ne déstabilise pas le système. Si un paquet a besoin de celui que l'on cherche à retirer, urpmi va alors demander de le désinstaller aussi. C'est un bon fonctionnement sécurisé. Cependant, il est parfois utile de désinstaller comme un sauvage une série de paquets sans pour autant faire jouer les dépendances. Par exemple pour ré-installer un composant qui a été corrompu. On va donc le désinstaller, j'insiste, sauvagement, puis demander à urpmi de le réinstaller à neuf.
Tout simplement... A noter pour les Windowsiens que l'on n'a pas sous Unix cette histoire de "erreur, fichier utilisé". Il est parfaitement possible par cette méthode (comme par urpme d'ailleurs) de désinstaller le serveur X complètement et de le réinstaller de A à Z.. sans quitter X 
Une autre commande utile est la possibilité de supprimer les paquets orphelins, c'est à dire ceux qui ne sont utilisés par aucun paquets :
PANIC: fatal region error detected
Il peut arriver que la base de données soit corrompue et que tout utilisation de la gestion de paquet soit ainsi bloquée. Contrairement à ce que l'erreur renvoyée suggère, ne paniquez pas :
Fabriquer un dépôt
Dans certain cas particulier il peut être intéressant de fabriquer ses propres medias compatibles avec URPMI. Pour cela il faut créer un dossier, mettre des rpm dedans, et, dans ce dossier, exécuter les commandes suivantes :
Voilà, le nouveau média est près à être ajouté.
Décompresser un RPM
Il est parfois bien utile de décompresser un fichier .rpm sans pour autant l'installer. Malheureusement les rpm utilisent un format un peu obscure et nécessite de passer par la commande rpm2cpio pour obtenir les contenus :
Equivalence avec le monde Debian
Le système de paquets .deb est utilisé avec l'utilitaire de gestion locale dpkg et de dépendances apt. Merci à Dab pour ces informations !
Dépôts
| Sujet | RPM | DEB |
|---|---|---|
| Wizzard | easyurpmi.zarb.org | ? |
| Dépôts | main/contrib/nonfree/plf | main,contrib,non-free |
| sous-dépots | release,update,testing,backport | stable,unstable,testing,backport |
| Ajout | urpmi.addmedia | ? |
| Suppression | urpmi.removemedia | prpmq --dump-config : vi /etc/apt/source.list |
Recherche
| Sujet | RPM | DEB |
|---|---|---|
| Simple | urpmq -Y openoffice | apt-cache search openoffice |
| Avec infos | urpmq -Yi openoffice | apt-cache show openoffice |
| Avec changements | urpmq --changelog openoffice.org | apt-listchanges --apt openoffice.org |
| Par fichier | urpmf /usr/bin/oowriter | dpkg -S /usr/bin/oowriter sinon il y a aussi apt-file |
Installation
| Sujet | RPM | DEB |
|---|---|---|
| Ajout | urpmi openoffice.org | apt-get install openoffice.org |
| Mise à jour | urpmi --auto-update | apt-get upgrade |
| Remplacement | urpmi --replacepkg enchant | apt-get --reinstall install enchant |
Base locale
| Sujet | RPM | DEB |
|---|---|---|
| Recherche | rpm -qa | grep -i xorg | dpkg -l | grep xorg |
| Liste | rpm -ql gzip-1.3.12-3mdv2009.0 | dpkg -L gzip |
| Informations | rpm -qi gzip-1.3.12-3mdv2009.0 | ? |
| Fichier | rpm -qf /usr/bin/ls | ? |
| Dépendances | rpm -qR pm-utils-1.2.0-3mdv2009.0 | apt-cache show pm-utils | grep Depends |
| Vérification | rpm -Va | dpkg -C |
Désinstallation
| RPM | DEB |
|---|---|
| urpme openoffice.org | apt-get remove openoffice.org |
| rpm -e --nodeps $(rpm -qa | grep -i xorg) | dpkg --force-depends remove xorg |
| urpme --auto-orphans | deborphan | xargs dpkg -P |
Divers
| Tâche | DEB |
|---|---|
| Reconstruction de base | ca n'arrive jamais parait-il |
| Fabrication de dépôt | Un tutoriel ici |
| Décompresser un paquet | ar -x package.deb |
Conclusion
La grande querelle a toujours été de savoir qui de .deb ou .rpm est le meilleur des systèmes de paquets. Fondamentalement ils font la même chose à une granularité près. L'important reste l'existence même d'un tel système qui simplifie considérablement la maintenance d'un système ou, d'un point de vue utilisateur, l'expérience même des logiciels libres.
]]>