Yoran 22 octobre, 2008 - 11:40 Médias et stockage
Gestion des paquets

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/relea... 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...
./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.

Vos remarques et commentaires...

tuxce, le 20 octobre, 2008 - 17:02

> "c'est que c'est un système indépendant qui est responsable de l'installation, pas l'application elle-même, et encore moins son auteur."

peut etre pas l'auteur du soft, mais bien des paquets fournissent des scripts post/pre suppression/maj/installation qui, étant donné qu'ils sont le plus souvent lancés en root ont tous les droits.

> "# rechercher (option -q) la liste de tous les fichiers installés (option -a) et
# de filtrer sur une clef donnée, ici xorg
gaston$rpm -qa | grep -i xorg"

pour s'éviter l'appel à grep:

rpm -qa "*xorg*"

> "La grande querelle a toujours été de savoir qui de .deb ou .rpm est le meilleur des systèmes de paquets."
pacman :D (ironie inside)

c'est juste pour en citer un autre, il est moins complet que les 2 pré-cités et il lui manque la vérification de la source mais est très simple à utiliser et le système de description de paquets est, on ne peut plus clair.

pour le reste, au risque de se répéter, des blogs de cette qualité, on en redemande ;)

Zanko, le 20 octobre, 2008 - 19:39

"La grande querelle a toujours été de savoir qui de .deb ou .rpm est le meilleur des systèmes de paquets."
Ah ? Y'a des gens qui se posent encore la question ? Deb rules !

Non sérieusement, je ne sais pas lesquels des .deb ou des .rpm sont les meilleurs, mais apt est génial et ultra complet, à mon avis supérieur à beaucoup de gestionnaires de paquets pour rpm. De plus, à l'exception notable d'urpmi, les gestionnaires de paquets rpm sont souvent lents, voire extrêmement lent dans le cas de yum (fedora).

Sinon très bon article, comme d'hab quoi. je le garde sous la main au cas où un jour je me retrouve sous Mandriva. Ça m'aurait bien aidé un tuto comme ça à l'époque où je débutais sous Linux.

<mavie>

Au tout début, ignorant tout de l'existence de ces merveilles que sont les gestionnaires de paquets et n'imaginant pas que quelque chose de si pratique puisse exister, étant habitué au monde (ou plutôt à l'enfer ^^) windows, je téléchargeais les paquets un par un sur rpmfind, pestant contre les dépendances...

</mavie>
tuxce, le 20 octobre, 2008 - 20:44

en même temps, je sais pas de quelle époque tu parles, mais il y a un moment, les .deb n'étaient pas aussi répandus, les dépot genre livna ou dries (pour fedora) n'était pas très fourni ni suivi, on était obligé de passer par un rpmfind et se battre avec les dépendances.

entre (), yum n'est pas plus lent que apt-get, à la différence près que yum remet systèmatiquement à jour la base (sauf option -C (de mémoire)) alors que apt-get le fait avec la commande "apt-get update".

Yoran, le 20 octobre, 2008 - 22:38

@tuxce
Ma formulation n'est pas très clair en effet. Pour moi le format paquet, et donc les scripts post et pre, font partis de la gestion de paquets. Lorsque je parle d'indépendance, je veux dire que ce n'est pas l'application contenue dans le paquet qui est responsable de sa propre installation. Même si l'auteur peut fournir certaines specs de paquets, c'est généralement au maiteneur du paquet qu'incombe cette tâche. A lui de savoir ce qu'il fait dans le système pour lequel il travaille.

Pour ce qui est de la syntaxe de -qa je l'aime moins que grep car je peux chercher moins de choses. Par exemple lorsque tu ne veux pas de distinction majuscules/minuscules (pratique pour les paquets perl).

Sinon pour packman, tu en as tellement parlé sur planet-libre que j'ai failli le citer ! Comme quoi l'évangélisme ça marche ;-) J'ai même tenté une installation de frugalware mais j'ai échoué dans ma vm.

PS: merci pour la remarque finale, ça fait toujours plaisir.

Yoran, le 20 octobre, 2008 - 22:47

@Zanko la lenteur des paquets rpm comme la supériorité des .deb, sans vouloir casser un mythe, est une légende :-) Et je dis cela sans agressivité. Le hasard m'a poussé à commencer sur une mandriva, j'aurais tout aussi bien pu commencer sur une Debian, mon avis aujourd'hui serait sûrement le même.

Concernant la supériorité, je connais pas mal les deux systèmes et techniquement, peu de chose les différencies. Les mêmes informations de base confinent au même résultat. Après ce n'est qu'une question d'implémentation des clients respectifs et leur capacité à exploiter les informations données dans les paquets.

Après pour la lenteur, là aussi c'est une simple question d'implémentation et de stratégie. Comme le souligne à juste titre tuxce, yum, mais aussi smart, met à jour sa base à chaque passage, urpmi et apt le font sur demande. Maintenant dire que l'un est plus rapide que l'autre...

Je suis persuadé que si je prenais le temps de skiner une mandriva pour qu'elle look comme ubuntu et que je wrappais urpmi dans un "apt-like", peu seraient capable de voir la différence ;-)

Dab, le 21 octobre, 2008 - 00:34

Nous avions déjà une discussion sur le sujet, à l'époque tu m'avais montré l'équivalence a peu de choses près des deux systèmes de gestion de packages. La seule différence que je vois est peu être le nombre d'architecture supportées.
PS: J'aime beaucoup la nouvelle colorisation des sources et l'absence de la numérotation des lignes bien plus pratique pour les copier/coller.

Yoran, le 21 octobre, 2008 - 01:01

@Dab Oui je me souviens :) En fait j'avais perdu cet article après une fausse manip, j'ai réussi à le retrouver dans un vieux backup et je l'ai donc restauré puis mis à jour. Mais j'ai plus les commentaires :/

Pour ce qui est des architectures, c'est plus une différence de la debian que de son format de paquets il me semble ?

re PS: Merci ;-) C'est le nouveau mode "traces". Pour les sources j'ai laissé les numéros de lignes mais tu n'as peut-être pas remarqué que lorsque tu survoles ce type de bloc avec ta souris, un onglet s'affiche en bas à gauche pour basculer en texte simple ?

Yoran, le 21 octobre, 2008 - 16:15

Petits soucis avec l'activation des commentaires, c'est revenu :)

Zanko, le 21 octobre, 2008 - 20:10

@Ulhume : c'est pour ça que je précisais que ce n'était pas des paquets dont je parlais mais des gestionnaires de paquets. Je doute d'ailleurs qu'en termes de fonctionnalités yum, urpmi & co égalent apt (d'ailleurs, y'a-t-il un équivalent à debconf avec les rpm ?). Par contre, les .deb, du peu que j'en ai vu, doivent être un peu plus fastidieux à créer.

Dab, le 21 octobre, 2008 - 21:41

> > En réponse à :
> > .... Pour ce qui est des architectures, c'est plus une
> > différence de la debian que de son format de paquets il me
> > semble ? ... Si si c'est bien lié au gestionnaire de package et
> > pour s'en convaincre : apt-cache show bash
> > Package: bash
> > Essential: yes
> > Priority: required
> > Section: base
> > Installed-Size: 1768
> > Maintainer: Ubuntu Core developers
> > Original-Maintainer:
> > Matthias Klose
> > Architecture: i386

> Alors pour le coup, s'il s'agit juste d'avoir l'info architecture
> dans les données du paquet, le RPM l'ont aussi ;-)
> Ce que je voulais dire c'est que dans les faits, Mandriva propose
> moins d'architectures que Debian.

Neni Debian va tout de même beaucoup plus loin, il gère vraiment les architectures:
apt-get update -o Apt::Architecture=arm
apt-cache search -o Apt::Architecture=arm search le_package
Et pour la liste des architectures supportées: dpkg-architecture -L

Yoran, le 21 octobre, 2008 - 21:43

@Dab ok, je te donne le point ;-) Ca sert pas vraiment tout les jours mais tu as gagné ;-)

Ah oui, j'oubliais de te dire ce que tu as gagné... le droit de me donner la liste des équivalents aux commandes rpm/urpmi sus-citées pour que je puisse les y mettre ;-))

Dab, le 21 octobre, 2008 - 23:03

Ah ouf, je t'aurai pas laché la-dessus ;)

Yoran, le 21 octobre, 2008 - 23:10

@Dab je te lacherais pas non plus sur ton "gain" ;-)

Dab, le 22 octobre, 2008 - 00:44

Heu j'avoue là j'ai loupé une étape, de quel gain parles tu ? le freerunner ?

Yoran, le 22 octobre, 2008 - 03:09

@Dab

Ah oui, j'oubliais te de dire ce que tu as gagné... le droit de me donner la liste des équivalents aux commandes rpm/urpmi sus-citées pour que je puisse les y mettre ;-)
Dab, le 22 octobre, 2008 - 10:50

Dépots: stable, testing, unstable + backport ( en main, contrib, non-free)
urpmi.removemedia -a /prpmq --dump-config : vi /etc/apt/source.list

Recherche:
urpmq -Y openoffice : apt-cache search openoffice
urpmq -Yi openoffice : apt-cache show openoffice
urpmq --changelog openoffice.org: aptitude changelog openoffice.org OU apt-listchanges --apt openoffice.org
urpmf /usr/bin/oowriter : dpkg -S /usr/bin/oowriter
sinon il y a aussi apt-file

Installation:
urpmi openoffice.org : apt-get install openoffice.org
urpmi --auto-update : apt-get upgrade
urpmi --replacepkg enchant : apt-get --reinstall install enchant

Base:
rpm -qa | grep -i xorg : dpkg -l | grep xorg
rpm -ql gzip-1.3.12-3mdv2009.0 : dpkg -L gzip
rpm -qR pm-utils-1.2.0-3mdv2009.0 : apt-cache show pm-utils | grep Depends
rpm -Va : dpkg -C

Desinstallation:
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

PANIC: fatal region error detected
=> n'existe pas sous Debian ;)

Fabriquer un dépôt: me suis pas penché sur le pb (voir http://www.debian.org/doc/manuals/repository-howto/repository-howto.fr.html )

Décompresser un Deb
ar -x package.deb

Voir aussi apt-key (gestion des clés d'authentification des packages), apt-howto-fr (guide apt), apt-spy (création du source.list fonction de la meilleure bande passante), apt-proxy (création serveur dépot en local) ....

Yoran, le 22 octobre, 2008 - 11:42

@Dab merci :) J'ai rajouté un nouveau chapitre avec toutes ces informations. Là où j'ai des ? ce sont les quelques manques que j'ai encore. Sinon, quel est le format de la base de donnée local en elle même, c'est comme avec Zaurus, une liste en texte ?

Dab, le 22 octobre, 2008 - 12:05

Ajout/suppression de dépots: vi /etc/apt/source.list
Base locale : Informations => Qu'elle est la signification de rpm -qi ... ?
Fichier : dpkg -S /usr/bin/ls (le package doit être installé)
La base est le fichier binaire /var/cahce/apt/pkgcache.bin, que l'on peut dailleurs supprimer car il sera regénéré lors d'un apt-get update.

Publier un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
  • To highlight piece of code, just surround them with <code type="language"> Your code &tl;/code>>. Language can be java,c++,bash,etc... Everything Geshi support.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <div> <p> <br>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.

Plus d'informations sur les options de formatage

CAPTCHA
Cette question est là pour déterminer si vous êtes humain ou pas...