Artisan Numérique

/système/paquets/mandriva/urpmi/ Gestion des paquets sous mandriva

Une des grandes forces du monde Unix, et donc de GNU/Linux, tient à sa capacité à installer et désinstaller très facilement des applications. Lorsque l'on arrive du monde Windows, cet aspect tient même du magique. C'est la fin des heures de recherche sur le net pour trouver un pov' logiciel, trouver son installation, l'installer, rebooter, comprendre ce qu'il a réellement installé, le désinstaller, pleurer parce qu'on n'y arrive pas...

Une des grandes forces du monde Unix, et donc de GNU/Linux, tient à sa capacité à installer et désinstaller très facilement des applications. Lorsque l'on arrive du monde Windows, cet aspect tient même du magique. C'est la fin des heures de recherche sur le net pour trouver un pov' logiciel, trouver son installation, l'installer, rebooter, comprendre ce qu'il a réellement installé, le désinstaller, pleurer parce qu'on n'y arrive pas...

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 :

rooturpmi.removemedia -a

rooturpmi.addmedia --update plf-free ftp://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/2009.0/free/release/binary/i586/ with media_info/hdlist.cz
...etc...

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 :

rooturpmq --dump-config
contrib.release http://somewhere.net/medias/2009.0/ftp.proxad.net/contrib/release
...
et pour une version directement exploitable
urpmq --dump-config | awk '{print "urpmi.addmedia $0"}'

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

Recherche d'un paquet simple, le Y en majuscule indique une recherche "floue"
gastonurpmq -Y openoffice
openoffice.org
openoffice.org-base
openoffice.org-calc
openoffice.org-common
etc...

Maintenant une recherche avec affichage des numéros de version par l'ajout de l'option -r
gastonurpmq -Yr openoffice
openoffice.org-3.0-0.rc2.2mdv2009.0
openoffice.org-base-3.0-0.rc2.2mdv2009.0
openoffice.org-calc-3.0-0.rc2.2mdv2009.0
openoffice.org-common-3.0-0.rc2.2mdv2009.0
etc...

On poursuite avec une recherche avec affichage de la liste
de tous les fichiers (option -l) contenus dans le paquets.
Pratique avec un grep pour chercher où va s'installer un fichier en particulier.
si nous avions remplacé "openoffice" par "openoffice.org-base", la même chose
serait affiché mais spécifiquement pour ce paquet
gastonurpmq -Yl openoffice
/usr/share/edos/tests/mandriva-manual-tests/OpenOffice
/usr/share/edos/tests/mandriva-manual-tests/OpenOffice/OpenOffice.xml
/usr/share/edos/tests/mandriva-manual-tests/OpenOffice/tc
/usr/share/edos/tests/mandriva-manual-tests/OpenOffice/tc/Integration.xml
/usr/lib/ooo-3.0/basis3.0
etc...

Maintenant une recherche plus précise avec affichage des informations sur les paquets (-i)
là aussi il auraitété possible de limiter à un seul paquet.
gastonurpmq -Yi openoffice
Name        : edos-mandriva-manual-tests-openoffice
Version     : 1.0.0
Release     : 4mdv2009.0
Group       : Development/Other
Size        : 1039                         Architecture: noarch
Source RPM  : edos-mandriva-manual-tests-1.0.0-4mdv2009.0.src.rpm
URL         : http://www.edos-project.org
Summary     : EDOS XML specification files for Mandriva manual test procedures (OpenOffice)
Description :
The EDOS XML specification files for Mandriva manual test procedures, for the
OpenOffice suite
etc...

Pour obtenir seulement les informations de changement sur un paquet
gastonurpmq --changelog openoffice.org
* Sat Oct  4 2008 Frederic Crozat <fcrozat@mandriva.com> 0:3.0-0.rc2.2mdv2009.0
- Add epoch to fix upgrade from Mdv 2009 RC2 and allow gnome subpackage to be installed

* Wed Oct  1 2008 Rafael da Veiga Cabral <cabral@mandriva.com> 3.0-0.rc2.1mdv2009.0
+ Revision 290159

Enfin, une autre recherche très pratique, savoir dans paquet se trouve un fichier donné
urpmf /usr/bin/oowriter
openoffice.org-writer:/usr/bin/oowriter3.0

Rechercher les paquets qui dépendent d'un autre paquet
gastonurpmq --whatrequires libunique0
marlin
midori
...

Installation d'un paquet

Lorsque nous avons trouvé ce que nous voulons, nous pouvons l'installer :

rooturpmi openoffice.org

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.

recherche des mise à jour dans les médias
rooturpmi.update -a

Lance une installation de tout ce qui est nouveau (attention en production !!!)
rooturpmi --auto-select

La même chose en une seule commande
rooturpmi --auto-update

Si vous avez des soucis de MD5, vous pouvez rajouter l'option -no-md5sum aux deux commandes et -force --allow-force en plus à la seconde.

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:

remplacement d'un paquet simple...
rooturpmi --replacepkg enchant libenchant1

remplacement de tous les paquets de gedit
urpmi --replacepkg $(rpm -qa | grep gedit)

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.

rechercher (option -q) la liste de tous les fichiers installés (option -a) et
de filtrer sur une clef donnée, ici xorg
gastonrpm -qa | grep -i xorg
libxorg-x11-devel-7.3-4mdv2009.0
x11-server-xorg-1.4.2-7mdv2009.0
xorg-x11-75dpi-fonts-7.3-4mdv2009.0


savoir de quel paquet vient un fichier installé (option -f)
gastonrpm -qf /usr/bin/zcat
gzip-1.3.12-3mdv2009.0

la même chose avec seulement le nom d'une commande
gastonrpm -qf $(which ls)
coreutils-6.12-2mdv2009.0

obtenir la liste des fichiers installés par un paquet
gastonrpm -ql gzip-1.3.12-3mdv2009.0
/bin/gunzip
/bin/gzip
/bin/zcat
/usr/bin/gunzip
/usr/bin/gzexe
/usr/bin/gzip
/usr/bin/zcat

obtenir la liste des paquets dont dépend un paquet
gastonrpm -qR pm-utils-1.2.0-3mdv2009.0
rpmlib(VersionedDependencies) <= 3.0.3-1
usermode
pciutils
radeontool
... pm-utils-1.2.0-3mdv2009.0
rpmlib(VersionedDependencies) <= 3.0.3-1
usermode
pciutils
radeontool


plus fort encore, obtenir la liste des fichiers modifiés depuis leur installation.
Le système anti-intrusion du pauvre en quelque sorte...
$rpm -Va
S.5....T    /usr/share/fonts/OTF/fonts.scale
S.5....T    /usr/share/fonts/Speedo/fonts.dir
S.5....T    /usr/share/fonts/Speedo/fonts.scale
S.5....T    /usr/share/fonts/TTF/fonts.dir
S.5....T    /usr/share/fonts/TTF/fonts.scale

il est aussi possible de spécifier un format avancé à rpm -q
gastonrpm -q -a --queryformat='%{N}-%{V}-%{R}.%{arch}\n'

Désinstallation

Pour supprimer une application, c'est aussi simple que ça :

rooturpme openoffice.org

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.

rootrpm -e --nodeps $(rpm -qa | grep -i xorg)

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 :

rooturpme --auto-orphans

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 :

Si vous obtenez ce genre de message en installant l'indispensable "tagazok"
rooturpmi tagazok
rpmdb: PANIC: fatal region error detected; run recovery
erreur: erreur db4(-30975) de dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery
erreur: ne peut ouvrir l'index Packages en utilisant db3 -  (-30975)

ou encore ce message là :
rooturpmi tagazok
rpmdb: Page 2: item 74 hashes incorrectly
rpmdb: /var/lib/rpm/Requirename: DB_VERIFY_BAD: Database verification failed
erreur: erreur db4(-30973) de db->verify: DB_VERIFY_BAD: Database verification failed

La solution est de regénérer la base
rootrm -f /var/lib/rpm/__db*
rootdb_verify /var/lib/rpm/Packages
rootrpm --rebuilddb

et hop, fin de l'alerte...
rooturpmi tagazok

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 :

gastonmkdir mon_depot
gastoncd mon_depot

recopie des rpm
gastoncp /quelquepart/*.rpm .

génération de l'indexation des rpm
gastongenhdlist2 .

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 :

pour éviter de mettre le zouzou dans le dossier courrant
gastonmkdir tmp_rpm
gastoncd tmp_rpm

extraction...
gastonrpm2cpio http://ftp.proxad.net/pub/Distributions_Linux/Mandrake/official/2008.0/i586/media/non-free/release/atunes-1.7.2-2mdv2008.0.noarch.rpm | cpio -idmv
./usr/bin/atunes
./usr/share/applications/mandriva-atunes.desktop
./usr/share/atunes
gastonls usr/bin/
atunes*

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.