Ainsi parla Georges Louge <[EMAIL PROTECTED]>, le  1 décembre de
l'an de grâce 2004 :
>   Moins évolué en quoi ? Que fait apt de plus, ou de mieux, que 
> urpmi ?

Merci d'avoir posé la question ! Alors, que fait apt de plus
qu'URPMI ? C'est ce que nous allons découvrir tout de suite avec, à ma
gauche, une Debian Sid et, à ma droite, une Mandrake Cooker.

1. Fichiers de données plus petits

Lorsqu'on met à jour sa base urpmi, on télécharge environ
50 Mo (main + contrib). Par contraste, avec APT, j'en suis à moins de
5 Mo, et un système à base de diff, plus économe, est en train
d'arriver (il y avait déjà un système non-officiel).

2. Épinglage (pinning)

J'ai une distribution assez à jour naturellement, mais j'utilise aussi
des sources alternatives (par exemple des versions CVS). Je ne veux pas
installer depuis ces sources automatiquement. APT me permet de régler
les priorités afin que je puisse toujours avoir leurs paquets
disponibles, mais que ceux de ma distribution habituelle leur soient
préférés si je n'interviens pas.

3. Paquets gérés automatiquement

Un frontal APT comme l'excellent Aptitude peut déterminer
automatiquement quels paquets ont été installés pour satisfaire les
dépendances d'un autre. Si ce dernier est enlevé, le logiciel se
débarrassera automatiquement des paquets devenus inutiles. Sur ma
Cooker, j'ai retrouvé pas moins de quatre (!) versions de la même
bibliothèque. Trois étaient obsolètes, mais le système n'avait pas
compris cela.

4. Frontaux de meilleure qualité

Le frontal urpmi (rpmdrake) semble être composé de deux logiciels dans
le Centre de contrôle Mandrake : un pour ajouter des logiciels et un
autre pour en enlever. Ceci est peu ergonomique, mais c'est un détail.
Le vrai problème est que ces logiciels ne sont guères intelligents.
Voici une session typique sur une machine où un grand nombre de
logiciels inutiles ont été installés :

 - je lance rpmdrake
 - je clique pour supprimer un premier logiciel
 - l'ordinateur mouline... mouline...
 - une fenêtre s'affiche m'indiquant que je ne peux désinstaller le
   logiciel à cause de 2567485 autres en dépendant (certains
   apparaissent x fois dans la fenêtre). Soit dit en passant, les
   dépendances sont parfois douteuses, j'y reviendrai
 - j'annule
 - je clique sur le suivant
 - l'ordinateur mouline... mouline... mouline...
 - rincez et répetez pour plusieurs dizaines de logiciels
 - je clique sur Supprimer
 - l'ordinateur mouline
 - une fenêtre m'annonce qu'un des logiciels que j'ai pu sélectionner
   sans que le programme y voie d'inconvénient ne peut en fait être
   supprimé
 - je jure comme un charretier
 - je retrouve le logiciel qui va bien (le message d'erreur indiquait
   myspell-fr, il n'existe pas c'est myspell-fr_FR). Je le déselectionne
 - je clique sur Supprimer
 - l'ordinateur mouline
 - je me rends compte que j'ai vachement bien fait de lancer ce truc
   depuis un terminal et non depuis le Centre de contrôle, car c'est
   dans celui-ci que s'affichent les opérations en cours, et les
   éventuels avertissements de RPM (répertoires impossibles à supprimer,
   par exemple)

Par contraste, avec Aptitude :

 - l'arbre des dépendances est créé au démarrage une fois pour toutes.
   Pas d'attente lors des opérations successives
 - je peux facilement voir l'arborescence des dépendances d'un
   programme, et tout supprimer facilement
 - le logiciel m'offre un écran permettant de voir les conséquences de
   mes choix avant de poursuivre
 - je n'ai pas à lancer X-Window pour l'utiliser (merci pour mes
   serveurs)
 - les opérations effectuées sont clairement visibles
 - le logiciel ne poursuit pas tant que toutes les dépendances ne sont
   pas satisfaites d'une manière ou d'une autre

5. (RPM vs. DPKG) Bases de données de paquets en clair

[EMAIL PROTECTED]|pts/61:~# file /var/lib/dpkg/available
/var/lib/dpkg/available: UTF-8 Unicode English text, with very long lines

[EMAIL PROTECTED] file /var/lib/rpm/Packages
/var/lib/rpm/Packages: Berkeley DB (Hash, version 8, native byte-order)

Question : si le disque dur a un problème quelconque, et que ces
fichiers sont endommagés, lequel des deux a le plus de chances d'être,
au moins partiellement récupérable ? Les bases RPM corrompues, ça
existe, David Vincent... non, *JE* les ai vues. Et ça ne m'a pas
enchanté. D'accord, ce n'est pas spécifique à APT mais URPMI est basé
sur RPM, donc je m'en soucie.

6. (RPM vs. DPKG) Debconf

Installer un logiciel complexe est souvent source de tracas. Tout
particulièrement lorsque son bon fonctionnement va dépendre de la
justesse de certains paramètres. Un paquet utilisant Debconf va poser
quelques questions intéractivement à l'utilisateur, et générer un
fichier de configuration à partir de celles-ci. Dans de nombreux cas, le
logiciel est opérationnel immédiatement dans la configuration que l'on
souhaitait (ainsi, l'installation de Postfix propose-t-elle différents
choix selon le type de site qu'on est, du simple particulier au serveur
de messagerie en production). Dans d'autres, la présence de Debconf aura
permis de régler un paramètre que l'on n'aurait probablement pas été
chercher tout seuls (ainsi, une boîte de dialogue m'a demandé quelle
méthode de lissage je souhaitais pour mes fontes selon que j'avais un
écran CRT ou LCD).

Un autre point intelligent : si un fichier de configuration n'est pas
la version originale, dpkg va proposer de le remplacer, le laisser tel
quel, voir les différences, ou interrompre temporairement l'opération
pour que je puisse intégrer les changements dans l'ancien. RPM va juste
planter un .rpmnew quelque part.

7. Autres considérations

Enfin, il y a d'autres choses, comme la qualité des paquets. Qu'est-ce
qu'un paquet de qualité ? C'est un paquet qui n'a pas de dépendances
foireuses pour commencer. Déjà, la capacité de RPM à indiquer des
dépendances sous la forme 'libtotofoobaz.so.6' est une hérésie :
indiquer un paquet permet d'installer le paquet facilement. Indiquer un
fichier fait partir l'utilisateur à la recherche du paquet contenant
celui-ci. Même en omettant ceci, il y a parfois des ces âneries. Tiens,
un bel exemple :

[EMAIL PROTECTED] urpmq -i dynamic | grep -A 2 Description
Description :
Create desktop entries for GNOME and KDE when a new peripheral is
plugged in the system (mainly USB devices).
[EMAIL PROTECTED] urpme dynamic
Pour satisfaire les dépendances, les paquetages suivants vont être désinstallés 
(0 Mo):
devfsd-1.3.25-40mdk.i586 (dynamic non satisfait)
dynamic-0.21-1mdk.noarch
Est-ce correct ? (O/n) n

On voit tous la nécessité absolue d'avoir le machin qui met des icones
sur le bureau lorsqu'on branche un truc pour un démon de bas niveau
comme devfsd. Les dépendances inutiles devraient être évitées. Il y a
aussi d'autres choses, comme fournir un fichier de configuration propre,
une page de manuel si le programme n'en a pas, etc. Debian m'apporte
tout ces petits détails. Mandrake, euh... ça dépend du vent. Un exemple
type du paquet excellemment bien fait est le XFree de Debian, maintenu
par un gourou de X, il est excessivement patché pour éviter la plupart
des bugs, livré avec une FAQ exhaustive, etc. Et le mainteneur, plutôt
que de se jeter sur la version de transition de chez X.Org dès sa
sortie, prépare une bascule en bon ordre vers la branche modulaire de ce
dernier. La qualité prime sur la nouveauté, et j'en suis fort aise.

>   J'ai déjà souvent lu ou entendu vanter la supériorité de Debian, 
> sans que jamais personne ne m'ait apporté l'ombre d'un commencement 
> de justification. Alors, pour le moment, je continue de penser que 

J'espère que les deux heures que je viens de passer à rédiger ce message
t'auront apporté un commencement de justification, ou l'ombre de
celui-ci. J'aurais pu encore citer les plus indéniables comme auto-apt,
qui détecte la tentative d'exécution d'un logiciel non présent, et le
télécharge à la volée, les très bons outils de création de paquets qui
m'aident à maintenir un dépôt privé pour mes versions personnalisées,
les dépôts tierces parties référencés sur apt-get.org, etc. Mais il faut
bien s'arrêter quelque part, et mon lit m'attend.

> c'est une idée reçue, ou bien un moyen de se poser comme plus 
> branché, plus spécialiste, ou plus professionnel.

Voilà. Je me sens terriblement branché, et ça me fait un plaisir
monstrueux de me faire tourner en dérision pour soi-disant « utiliser
une distrib vieille de deux ans », « impossible à installer » et
toutes les autres fables que l'on colporte sur Debian. Si, si.

(Oui, c'est du sarcasme, des fois que ça ne se remarque pas).

>   Le jour où les tenants de Debian m'apporteront des faits précis, 
> solides, vérifiables prouvant la supériorité de leur distribution 
> favorite, je suis tout prêt à reconnaître qu'ils ont raison. Mais 
> voici 7 ans que j'entends ce discours, et j'attends toujours...

Voilà qui est fait. Maintenant, je suis *certain* que l'on va me trouver
d'autres points en faveur de Mandrake. Tout comme je suis certain qu'il
y en a en faveur de la SuSE (j'aime bien leur système de scripts
d'initialisation, il est plus logique et mieux conçu. Voilà, c'est dit),
de la Fedora, de ce-que-vous-voulez-ici. Mais le problème, c'est que ce
n'est pas un concours de qué....tes. Il se trouve que toutes ces
distributions sont différentes parce qu'elles s'adressent à un public
différent (paf, révélation !). Dans ces conditions, déterminer quelle
est la « meilleure » de ces distribs a autant de sens que comparer une
VW Golf avec un sémi-remorque Scania 420. Alors, pourrait-on maintenant
enterrer ce troll vélu qui n'a aucune justification ?

+++
-- 
   Jacques Caruso |    Administrateur système    | Laissez-vous pousser
[EMAIL PROTECTED] |   Webmaster, jeuxdroles.org  | les dents. Ne marchez
(+33) 493 847 728 | Membre des Minotaures du Sud | pas sur les opossums.
 PGP : 0x41F5C63D |     Membre de Linux-Azur     | Mangez des kiwis.

Linux-Azur :      http://www.linux-azur.org
Désinscriptions: http://www.linux-azur.org/liste.php3
**** Pas de message au format HTML, SVP ****

Répondre à