Forums d'entraide informatique - Astuces - Conseils

TOUR D'HORIZON DES OUTILS APT*
dei
[...]
Lecture des listes de paquets... Fait
W: Aucune clé publique n'est disponible pour la/les clé(s) suivante (s):
A700AF53607003A1
[...]
Le message est clair, vous ne disposez pas de la clef publique permettant de vérifier la signature de l'archive. Il vous faut donc récupérer cette clef avec GnuPG
% gpg --recv-keys 6070D3A1 % gpg --list-key 6070D3A1
pub    1024D/6070D3A1 2006-11-20 [expire: 2009-07-01]
uid    Debian Archive Automatic Signing Key
(4.0/etch) <ftpmaster@debian.org>
Puis exporter une version ASCII de la clef pour la « tuyauter » vers apt -key
% gpg --export -a 607003A1 I sudo apt-key add - OK
Dans le cas présent, le problème ne se pose pas si le paquet debi an-archi ve- key ri ng est installé et à jour. Cependant, pour des archives non officielles, il peut être nécessaire d'ajouter de la sorte la clef publique.
Pour l'heure, la chaîne est la suivante
•    L'authenticité de Release peut être vérifiée grâce à sa signature GnuPG.
•    On peut vérifier l'intégrité des fichiers Packages grâce aux hashs et les hashs sont forcément de confiance, puisqu'ils proviennent du fichier Release.
•    Les fichiers Packages contiennent les hashs pour les différents paquets.
Il est donc très facile de vérifier chaque paquet et c'est précisément ce que fait la nouvelle version d'APT. La commande apt- key vous permet de gérer les différentes clefs disponibles. En installant debi an- archi ve-keyri ng,vous importez directement les clefs publiques Debian dans la liste.Vous pouvez à tout moment consulter cette dernière avec apt-key list.
La sortie fournie par aot -cache show n'est pas toujours des plus faciles à lire en termes d'analyse des dépendances. Cet avis est également celui de Simon Law qui a donc décidé d'écrire un petit outil permettant de déterminer plus simplement les dépendances : apt- rdepends.
Le plus simple et le plus convaincant est encore de vous montrer un exemple
% apt-rdepends bc
Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait
bc
Dépend: libc6 (>= 2.3.2.ds1-4) Dépend: libncurses5 (>= 5.4-1) Dépend: libreadline4 (>= 4.3-1) libc6
Dépend: libdbl-compat
libdbl-compat
Dépend: libc6 (>= 2.2.5-13) libncurses5
Dépend: libc6 (>= 2.3.2.ds1-4) libreadline4
Dépend: libc6 (>= 2.3.2.ds1-4) Dépend: libncurses5 (>= 5.4-11
Non seulement apt-rdepends vous liste les dépendances de bc, mais également, récursivement, les dépendances des dépendances. Vous obtenez une liste complète et claire des liens existant entre les paquets.
L'option -r vous permet de lister les dépendances inverses ou, autrement dit, la liste complète des paquets qui ont besoin de celui spécifié en argument.Autant vous dire qu'il n'est ni utile, ni très rusé de tenter l'expérience avec le paquet 1 i bc6. Plus utile, l'option -p permet d'ajouter à la sortie une mention d'état (Installed/NotInstalled). Un grep sur la sortie est une bonne manière d'obtenir rapidement la liste des paquets à installer sans utiliser apt-get.
Enfin, dans le registre des options qui ne sont pas vraiment utiles, mais qu'on aime utiliser par curiosité, nous avons -d permettant de générer un fichier de graphe au format Dotty.On redirigera la sortie standard vers un fichier pour traiter les données par la suite avec la commande dotty. Plus amusant et, sans aucun doute, plus décoratif (mais moins que le poster/calendrier inclus dans ce magazine), nous pouvons directement traiter les données Dotty via dot pour produire un graphe PostScriptA3 (en orientation paysage) que nous envoyons à l'imprimante par défaut
% apt-rdepends -d irssi I \
dot -Gsize=14.693,16.535" -Grotate=90 -Gratio=auto -Tps I \ lor

Les fichiers de configuration ne sont pas les seuls éléments de données qui sont purgés avec l'option - -purge d'apt-get. Certains paquets installent, par exemple, des utilisateurs ou des groupes. D'autre part, l'utilisation de cette option n'implique pas forcément la suppression de la configuration.Ainsi, en remplacement ou en complément à dpkg I grep Arc, on peut utiliser deborphan - - fi ndconfi g qui couvre un plus vaste nombre de possibilités (mais implique l'installation de deborphan qui a besoin, par exemple, de dial og).
dpkg et grep liste les paquets à purger, cut récupère leur nom et dpkg -P les purge. Mais là encore, l'automatisation complète n'est parfois pas souhaitable et mieux vaudra archiver les fichiers de configuration auparavant ou procéder manuellement.
Enfin, l'utilisation de dpkg -L suivi du nom du paquet permet de connaître l'emplacement et le nom du ou des fichiers de configuration :
% deborphan --find-config lessdisks
% dpkg -L lessdisks /etc/lessdisks-install.conf
(D- POPULARITY-CONTEST
Je l'ai dit plus haut, plus un système est vieux, plus l'espace disque se réduit naturellement. Nous venons de couvrir des problèmes propres à la gestion des paquets, mais il nous reste à régler le problème le plus important : celui entre la chaise et le clavier.
Un bon système gestion de paquets permet de tester rapidement n'importe lequel d'entre eux. Cela permet également d'en installer un très grand nombre en se disant allègrement « je désinstallerai ça plus tard ». Et le paquet demeure sur le système et finit par être oublié.
Un projet appelé « Debian Popularity Contest » a été mis en place de longue date. Son but est de déterminer
quels paquets, en dehors de ceux indispensables au fonctionnement de la distribution, sont importants pour les utilisateurs. A l'heure actuelle, une distribution Debian GNU/Linux dans son intégralité occupe plus de vingt CD-Roms d'installation. Bien que le Net fournisse le média par excellence pour installer GNU/Linux, il est important de pouvoir minimiser le nombre d'images ISO qu'un utilisateur doit télécharger. Mieux encore, il doit être possible d'installer un système viable, mais surtout satisfaisant avec un seul CD. Il faut donc déterminer quels paquets doivent trouver leur place sur ce premier CD d'installation.
Le résultat des travaux se présente sous la forme d'un paquet popul a ri ty -contest contenant un script installé par défaut. Celui-ci est lancé régulièrement via crond et va scanner l'ensemble du système pour maintenir une liste de paquets sous la forme :
1163915259 1153751347 dpkg /usr/bin/dpkg-query 1163915259 1155493105 bash /bin/sh
1163915258 1155493112 login /bin/su
Les deux premières valeurs sont respectivement la date d'accès et la date de modification au format UNIX du binaire spécifié à la fin de la ligne. Le nom du paquet concerné est indiqué à la troisième position. Le fichier est automatiquement créé de manière hebdomadaire et se trouve dans /va r/log/popul a ri ty contest.Cette liste est alors envoyée par mail, « anonymisée » et utilisée à des fins statistiques. La configuration de popul arity-contest se fait via /etc/popul a ri ty -contest .conf et peut être désactivée en spécifiant PARTICI PATE="no".
Mais il y a mieux encore. Les paquets pour lesquels le fichier de référence n'a pas été accédé depuis plus d'un mois sont marqués, en fin de ligne, par le tag <0 LD>. Un simple coup d'oeil dans le fichier journal ou en sélectionnant les lignes sur la sortie standard lors de l'exécution du script, nous permet d'obtenir un résultat intéressant :
1160423386 1143974170 oops /usr/sbin/oops <OLD>
1160423385 1153752326 xinetd /usr/sbin/xinetd <OLD> 1160423383 1155493244 snmpd /usr/sbin/snmpd <OLD>
1160423381 1153752262 smartmontools /usr/sbin/smartctl <OLD>
Le format utilisé pour la date est un timestamp UNIX, le nombre de secondes écoulées depuis le I er janvier 1970 à minuit. Il existe plusieurs manières de convertir ce format en une date lisible par un humain. La plus simple est d'utiliser la commande date avec :
% date -d '1970-01-01 UTC 1160423386 seconds"+%damaY'

Pour installer automatiquement ces paquets, il suffit d'utiliser apt-get bui 1 d- dep et le nom du paquet. Enfin, on télécharge les éléments du paquet source avec apt- get source bc
% apt-get source bc
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Nécessité de prendre 387ko dans les sources.
Réception de: 1 http://ftp.fr.debian.org testing/main bc 1.06-20 (dsc) [7360] Réception de: 2 http://ftp.fr.debian.org testing/main bc 1.06-20 (tar) [279kB] Réception de: 3 http://ftp.fr.debian.org testing/main bc 1.06-20 (diff) [107kB] 387ko réceptionnés en Os (391ko/s)
apt-get télécharge les trois fichiers nécessaires en fonction des informations présentes dans le fichier Sources, lui-même lu grâce aux informations de votre sources. I i st.
gpg: Signature faite le sac 07 oct 2006 19:39:32 CEST avec la clé RSA ID 0AC5BE61
gpg: Impossible de vérifier la signature: clé publique non trouvée
Le contenu du fichier bc_1. 06-20. dsc est authentifié grâce à sa signature GnuPG. Ici, cette vérification échoue, car nous ne possédons pas la clef publique du responsable du paquet dans notre trousseau. Un simple gpg - recv- key 0AC5BE61 et le message n'apparaît plus, preuve que la signature est bonne. Le fichier bc_1.06-20.dsc contient également les sommes de contrôle des fichiers bc_1.06. orig.tar.gz et bc_1.06-20.diff.gz.
dpkg-source: extracting bc in bc-1.06 dpkg-source: unpacking bc_1.06.orig.tar.gz dpkg-source: applying ./bc_1.06-20.diff.gz
Enfin, les sources en version amont sont désarchivés dans un répertoire bc-1.06 et le patch Debian est appliqué. Nous obtenons, au final, une version Debian des sources dans ce répertoire. À partir de ce moment, nous sommes en mesure de construire un paquet binaire à partir de ces données.
Remarquez qu'apt-get source fait un certain nombre de manipulations à votre place. S'il vous arrive d'endommager le contenu du répertoire des sources Debian, il n'est pas nécessaire de refaire appel à apt-get.Vous pouvez, tout simplement,supprimer le répertoire en question,puis utiliser
% dpkg-source -x bc 1.06-20.dsc
dpkg-source: extracting bc in bc-1.06 dpkg-source: unpacking bc_1.06.orig.tar.gz dpkg-source: applying ./bc_1.06-20.diff.gz
La construction à proprement parler se fait avec l'outil dpkg-bui ldpackage. Il suffit d'entrer dans le répertoire des sources et d'utiliser
% dpkg-buildpackage -b -rfakeroot
dpkg-buildpackage: source package is bc dpkg-buildpackage: source version is 1.06-20
[...]
dh_testdir
./configure --prefix./usr --with-readline
dpkg - bui I dpackage se charge de tout. Il lance la configuration des sources selon les besoins spécifiés dans les fichiers de configuration du paquet, puis passe à la compilation proprement dite
[...]
/usr/bin/make CFLAGS."-02 -g -Wall -D_POSIX_SOURCE -DDOT_IS_LAST" make[1]: entrant dans le répertoire " /mnt/six4/temp/bc-1.06 /usr/bin/make all-recursive
make[2]: entrant dans le répertoire " /mnt/six4/temp/bc-1.06 Making ail in lib
make[3]: entrant dans le répertoire " hint/six4/temp/bc-1.06/lib if gcc -DHAVE_CONFIG_H    -I. -I. -I.. -I. -I.. -I./../h
-g -02 -Wall -funsigned-char -02 -g -Wall -D_POSIX_SOURCE
-DDOT_IS_LAST -MT getopt.o -MD -MP -MF ".deps/getopt.Tpo"
[...]
make[3]: quittant le répertoire " /mnt/six4/temp/bc-1.06/dc Making all in doc
make[3]: entrant dans le répertoire " /mnt/six4/temp/bc-1.06/doc make[3]: Rien à faire pour " all ".
En fin de processus, divers outils propres à la distribution Debian sont utilisés pour vérifier l'état des données, nettoyer les sources ou encore configurer les documentations
[...]
dh_testdir dh_testroot dh_clean -k
[...]
dh_builddeb -pbc
dpkg-deb: construction du paquet "bc" dans "../bc_1.06- 20_i386.deb".
dh_testdir -pdc
La construction du paquet est la dernière étape :
[...]
dpkg-deb: construction du paquet "dc" dans "../dc_1.06-20_i386.deb". dpkg-genchanges -b
dpkg-genchanges: envoi d'un binaire - aucune inclusion de code source dpkg-buildpackage: binary only upload (no source included)
signfile ../bc_1.86-21i386.changes

Si vous disposez d'une installation fonctionnelle de GnuPG, la phrase de passe protégeant votre clef privée vous sera demandée afin de signer le fichier bc_1.06- 20 j386.changes.
Nous avons ici utilisé deux options avec dpkg -buildpackage. La première, - b, permet de demander uniquement la construction d'un paquet binaire. En l'absence de cette option, de nouveaux fichiers sources seront fabriqués. Bien entendu, l'archive des sources amont ne changera pas, mais le patch et le fichier de description (.dsc) seront mis à jour. Il n'est habituellement pas nécessaire de procéder de la sorte, sauf si vous devenez le nouveau responsable du paquet. On remarquera, à ce propos, que la procédure de signature du fichier de description ne fonctionnera pas étant donné que vous ne disposez pas de la clef publique du responsable officiel (John Hasler pour ce qui concerne le paquet bc).
Enfin, l'option -r et l'argument fakeroot permettent de construire le paquet sans être super-utilisateur. En effet, le paquet binaire contient une arborescence qui sera copiée sur la racine du système de fichier lors de l'installation. Il faut donc, si nécessaire, pouvoir donner aux fichiers de cette arborescence les privilèges et « appartenances » au root. C'est précisément ce que permet de faire fakeroot.  L'option -r sert simplement à préciser le programme permettant d'obtenir les privilèges root.
Au terme du processus,vous trouverez le ou,dans le cas présent, les paquets binaires dans le répertoire parent du répertoire des sources. Il vous suffira alors de lancer l'installation avec dpkg -i et le nom du ou des fichiers .deb :
% sudo dpkg -i ../bc_1.06-20_i386.deb
(Lecture de la base de données...
131920 fichiers et répertoires déjà installés.) Préparation du remplacement de bc 1.06-20
(en utilisant ../bc_1.06-20_i386.deb)
Dépaquetage de la mise à jour de bc
Paramétrage de bc (1.06-20) ...
(D SIMPLIFIEZ-VOUS LES CHOSES AVEC APT-SRC
apt-src automatise donc tout simplement les étapes décrites plus haut. La commande apt-src i nstal 1 bc (après un apt-src update) donnera les mêmes résultats qu'aptget source bc, installant dans le répertoire courant une arborescence de sources patchés prêts à être compilés. apt-src prend également en charge l'installation des dépendances binaires et de construction.Ainsi, le simple fait de demander l'installation des sources d'un paquet provoque l'installation des dépendances et des paquets -dev nécessaires.
Immédiatement après, et sans changer de répertoire, nous utiliserons la commande apt-src build bc pour obtenir nos deux paquets bc et dc que nous pourrons installer dans la foulée (via sudo).
L' NOTE
On peut également utiliser l'option -i permettant d'installer automatiquement le ou les paquets construits. A utiliser avec précaution cependant. Comme dans le cas de bc,cette option utilisée avec des paquets sources produisant plusieurs paquets binaires provoquera l'installation de tous les paquets binaires générés (ici bc, mais aussi dc). Ce qui n'est pas nécessairement souhaitable.
Mais le principal avantage d'apt-src est le suivi des sources installés. En effet, n'ayant pas d'emplacement spécifiquement dédié, les arborescences sources peuvent rapidement se retrouver un peu partout dans le système de fichiers. En particulier, si nous n'êtes pas particulièrement rigoureux dans vos manipulations.Ainsi,apt- src 1 i st vous permettra d'obtenir les emplacements de toutes les arborescences sources déjà installées :
Certaines actions d'apt-src nécessitent le passage en root. L'utilitaire gère automatiquement cela en vous demandant votre mot de passe (si vous êtes dans la liste des sudoers).
La reconstruction d'un paquet binaire à partir des sources Debian via la méthode classique peut être vite lassante. Pour nous faciliter les choses, l'utilitaire apt-src a été créé par Joey Hess. L'un de ses principaux avantages est de pouvoir être utilisé par un utilisateur standard. Comme vous l'aurez compris en lisant ce qui vient d'être détaillé, l'installation des sources d'un paquet n'est pas dépendant d'une arborescence prédéfinie comme pour les paquets binaires (/va r/cache/apt et /va r/1 i b/apt).
% apt-src list
i bc    1.06-20 /mnt/temp/bc-1.06
i wcalc 2.2.2-2 /home/denis/DEB/wcalc-2.2.2
On pourra supprimer une arborescence en utilisant aptsrc remove et le nom du paquet. L'action version suivie du nom d'un paquet permettra d'afficher le numéro de version des sources installés.

Enfin, on notera la possibilité de renseigner apt-src sur la présence d'une arborescence installée indépendamment avec l'action import. L'action upgrade permettra de mettre à jour l'ensemble des arborescences sources installées. apt-src devient rapidement plus agréable à utiliser que le couple apt-get source et cipkg-bui ldpackage. Mais si vous êtes un accro de la reconstruction, il y a peut être mieux...
p ENCORE PLUS SIMPLE APT-BUILD
Alors qu'apt-src permet « d'en mettre un peu partout », l'utilitaire apt -bui 1 d est bien plus rigoureux et installe une hiérarchie qui lui est propre dans /var.Ainsi, les paquets sources seront par défaut téléchargés, placés et construits dans /var/cache/apt-build/bui 1 d. Ceci peut-être modifié lors de l'installation d'apt-bui 1 d. L'outil de configuration des paquets (debconf) vous demandera de préciser certains éléments à ce moment.
Ainsi, vous serez amené à préciser (ou laisser les valeurs pas défaut) différents éléments de configuration
•    Le répertoire de stockage des arborescences sources.
•    Le répertoire de stockage des paquets binaires produits.
•    Le niveau d'optimisation entre -01 et -03. Un haut niveau d'optimisation provoque un temps de compilation plus important, mais aussi, parfois, certains problèmes de stabilité.
•    L'ajout ou non d'une ligne deb file: /var/cache/apt- bui 1 d/reposi tory apt-bui 1 d main dans votre sources .1 i st (notez que la configuration ne prend pas en compte la possibilité de répartir les sources dans des fichiers /etc/apt/sources.list.d/.
•    Les options et arguments à utiliser avec le compilateur GNU gcc (voir ci-après).
•    Les options à utiliser pour cake.
•    L'architecture de base du système parmi plusieurs options possibles qui apparaîtront en fonction du CPU détecté. Notre système de test est un AMD. Le système de configuration nous propose donc, k6, athlon-tbird, athlon-mp, athlon-fx, etc. Si votre architecture n'est pas listée, vous devrez en choisir une quelconque, puis éditer le fichier /etc/apt/apt-build.conf manuellement et, en particulier, la ligne mtune. Il s'agit en réalité de l'option -mtune passée à gcc et permettant
de spécifier un paramètre réglant l'optimisation de l'ordonnancement des instructions pour un processeur donné. Le compilateur est, en effet, capable de produire un code binaire qui sera mieux ordonnancé via l'utilisation des pipelines. Le gain de performance peut être, selon les applications, tout à fait significatif.
Revenons un instant sur l'option -mtune.Précisons d'emblée que, dixit la documentation GCC, l'option -mcpu est obsolète et synonyme de -roture pour les architectures i386 et x86-64. Il est important de le préciser, car certaines versions des pages de manuel ne sont pas à jour. Le point important est de bien comprendre que cette option n'est pas dépendante de l'architecture dans le sens où elle ne casse pas la compatibilité. Un fichier source compilé avec l'option -mtune=athl on- xp fonctionnera parfaitement sur un i586.
Nous avons également l'option -march. Celle-ci permet d'obtenir des binaires utilisant les instructions spécifiques d'un processeur ou d'une famille de processeurs. MMX, SSE, SSE2, 3dNOVV!, enhanced 3dNOVV! ou encore 555E3 sont des sets d'instructions. SSSE3, par exemple, est spécifique aux Intel Xeon et Intel Core 2 (mais il faudra attendre GCC version 4.3 pour les utiliser). Pour autoriser le compilateur GNU à se servir de ces jeux d'instructions spécifiques, il suffit de préciser l'architecture avec -ma rch. Notez que l'option implique automatiquement un -mtune identique.
On peut également jouer sur les deux options pour obtenir un binaire, par exemple, capable de fonctionner sur toute architecture supportant les instructions MMX (-ma rch=penti um-mmx), mais optimisé pour l'ordonnanceur d'un Athlon XP (-mtune=athl on- xp.II en résultera un binaire optimisé pour Athlon XP qui ne pourra fonctionner que sur processeurs MMX. Dans la pratique, cela reste très dépendant du code source. Un simple hel 1 o World fonctionnera sans doute très bien sur un Pentium même compilé avec -march=athl on-xp (non testé).
Remarquez que c'est bien -mtune qui est utilisé par apt -
bui 1 d. L'option -ma rch a été retirée avec la version 0.1 1.5, car elle posait des problèmes sur certaines architectures. En effet, par exemple, il ne semble pas y avoir de valeur pour cette option concernant les architectures PPC. On utilise alors -ificpu (eh oui !), qui reste valable pour cette architecture.
Pour obtenir des binaires optimisés et spécifiques à votre machine, il est donc conseillé d'utiliser -march en guise d'option pour gcc et s'assurer que -mtune soit vide ou identique.
Pour connaître les bonnes options, commencez par déterminer avec exactitude le modèle de processeur de votre machine :

RECOMPILER ET RECONSTRUIRE SES PAQUETS
                       
        % cat /proc/cpuinfo               
        processor : 0               
        vendor_id : AuthenticAMD               
        cpu family : 6               
        model    : 8               
        model name : AMI Athlon(tm) XP 2400+ stepping    : 1               
        cpu MHz    : 1993.744               
        cache size : 256 KB               
        [...]               
        Les indications importantes sont cpu family et model . Ensuite, le plus simple est de consulter les documentations des distributions basées fortement sur les sources. Gentoo est un excellent exemple http://frgentoo-wiki.com/HOWTO_CFLAGS. De là, on tire la ligne d'options idéale pour gcc : -march=athl on- xp -pipe -fomit-frame-pointer (l'option -02 est spécifiée par ailleurs dans la configuration d'apt-bui 1d).               
        Votre apt-bui Id est prêt. Il ne vous reste plus qu'à lancer la construction et l'installation du paquet avec               
% sudo apt-build install bc
--> Installing build dependencies (for bc) <--
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
[...]
--> Updating package lists <--
[...]
--> Downloading source bc (1.06-20) <--
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
[...]
--> Building bc <--
dpkg-buildpackage: source package is bc
dpkg-buildpackage: source version is 1.06-20
[...I
-> Cleaning up object files <--
Cleaning in directory •
dh_testdir
[...]
--> Moving packages to repository <--
--> Building repository <--
1...]
Les NOUVEAUX paquets suivants seront installés:
bc
0 mis à jour, 1 nouvellement installés, OU
enlever et 110 non mis à jour.
Il est nécessaire de prendre 0o/66.2ko dans les archives. Après dépaquetage, 193ko d'espace disque
supplémentaires seront utilisés.
Sélection du paquet bc précédemment désélectionné.
Dépaquetage de bc (à partir de .../archives/bc_1.06-20_1386.deb) Paramétrage de bc (1.06-20) ...
En une seule commande, les sources sont téléchargés et compilés avec nos options, les paquets binaires sont créés et le paquet demandé est installé. Notez que br et dc sont créés, mais que seul bc est installé sur le système.
ATTENTION
Il est important de noter que les lignes qui défilent lors de la compilation des sources ne semblent pas faire mention de nos options d'optimisation. Comme le précise le README.Debi an, c'est parfaitement normal. Les lignes que vous voyez sont les commandes utilisées par make, mais le wrapper fait son travail et les binaires sont bien produits tels qu'attendu.
Un autre élément important avant la grosse surprise concerne la priorité des paquets. Il est important de placer dans son / etciapt/preferences quelques lignes comme
Package: *
Pin: release azapt-build Pin-Priority: 800
Ainsi, vous serez sûr que les paquets construits sont bien ceux qui seront installés automatiquement.Vous pouvez, bien entendu, utiliser l'action bai Id-source en lieu et place d'i nstal 1 pour installer ensuite le ou les paquets présents dans /va r/cache/apt-bui I d/reposi tory avec dpkg Mais vous perdez alors tout l'avantage du système de gestion de dépendances.
Mais venons-en à la partie la plus amusante.Vous n'êtes pas satisfait du manque d'optimisation et vous êtes à deux doigts de reconstruire un par un tous les paquets installés ? apt -bai d a une option pour vous : apt-bui 1 d worl d. Cette commande magique doit être précédée de la génération d'une liste de paquets avec
% dpkg --get-selections I \
awk    ($2=="install") print $1}' \
> /etc/apt/apt-build.list
Il vous faut ensuite supprimer de cette liste de paquets ceux qu'il n'est pas souhaitable de reconstruire.Soit parce que c'est inutile, comme le compilateur GCC qui utilise son propre compilateur, soit parce que Debian prévoit un autre système, comme pour le noyau Linux. Il existe également des paquets non-free, comme acroread, pour lesquels on ne dispose pas des sources.
Ceci fait,vous n'avez qu'à utiliser a pt - bail d worl d et faire preuve de beaucoup de patience.Au terme du processus, vous devrez avoir, sur votre système, tous les paquets spécifiés dans la liste en version recompilée et optimisée pour votre architecture.
Avec ce type d'utilisation d'apt-build, on se rapproche clairement des optimisations de binaires, telles qu'on en trouve dans des distributions comme Gentoo. On notera cependant qu'on est loin de la souplesse des outils de ce type de distributions, et pour cause, Debian n'est pas une distribution source.

Comment trouver un paquet qui répond à vos besoins dans une distribution ? La prochaine distribution Debian Stable sera sans doute constituée de quelques 22 CD (ou 3 DVD) et les outils de recherche basés sur les descriptions de
paquets montrent déjà leurs limites. Illrut trouver une autre solution.
or
Quel est le problème ? La réponse tient en une seule commande
% apt-cache stats
Nombre total de paquets : 29777 (1191k) Paquets ordinaires : 23139
Paquets entièrement virtuels : 1092 Paquets virtuels simples : 1043 Paquets virtuels mixtes : 554
Manquants : 3949
29777 paquets, soit une meule de foin énorme où chaque utilisateur cherche son aiguille. Les outils comme apt- cache search bien que très utiles ne sont pas conçus pour trouver un paquet autrement que par leur nom ou un mot qui puisse se trouver dans leur description. Comment trouver, en effet, tous les éditeurs de texte en mode console sans en connaître le nom ? Vous me direz qu'il suffit de faire apt-cache search text editor. Cela fonctionne, nous obtenons une liste, mais le résultat n'est pas celui attendu.
Une première solution pour régler le problème est celle jusqu'alors utilisée. Elle consiste à faire usage de sections et de classer les paquets à l'intérieur. Il existe une trentaine de sections définies arbitrairement. Elles permettent par exemple à l'outil deborphan de fonctionner en analysant les dépendances des paquets pour les sections « oldlibs » et « libs ».
Cependant, le système de sections n'est pas suffisant. Non seulement un paquet ne peut se trouver que dans une seule section, mais le nombre de sections est insuffisant. 30000 paquets dans 30 sections nous donnent 1000 paquets par section, ce qui n'avantage pas l'utilisateur. Pire encore, en augmentant le nombre de sections (si c'est possible), nous réduisons certes le nombre de paquets pour chacune d'elles, mais comment l'utilisateur fera-t-il pour choisir parmi 150 sections de 200 paquets ?
Cet état de fait est tellement évident qu'un rapport de bogue de niveau « wishlist » a été introduit dans le BTS Debian il y a fort longtemps. Le bogue 144046 date de janvier 2002.
LA SOLUTION VENUE D'INDE
Enrico Zini, développeur Debian, s'est penché sur le problème et a fait une découverte très intéressante : les problèmes de classification de logiciels sont identiques aux problèmes de classification des livres. Or, justement, les bibliothèques ne datant pas d'hier, un grand nombre de recherches scientifiques à propos de la classification des ouvrages ont été faites. Si les problèmes sont les mêmes, les solutions le sont également. Comme le fait remarquer avec humour Enrico Zini dans l'un de ces documents présentant sa solution, un mathématicien bibliothécaire indien a initié un projet secret de classification des logiciels pour Debian dès 1931. Il n'a simplement pas utilisé les mots « logiciels » et « Debian », mais « livres » et « bibliothèque » (sans doute pour coder ses travaux !). Ce mathématicien bibliothécaire est Shiyali Ramamrita Ranganathan. Enrico Zini a eu l'idée d'appliquer les cinq lois de Ranganathan (voir encart) aux paquets/logiciels d'une distribution Debian
I. Les logiciels sont faits pour être utilisés. Ceci signifie que les utilisateurs souhaitant se servir des logiciels doivent pouvoir avoir connaissance de leur existence. Si un logiciel n'est pas connu, il est inutile et cela viole cette première loi.
2.A chaque utilisateur son logiciel. L'utilisation de tous les logiciels n'est pas appropriée à tous les utilisateurs. L'utilisateur ne doit pas simplement trouver un logiciel, il doit trouver le logiciel qui lui convient.
3.A chaque logiciel son utilisateur. Inversement un logiciel ne peut s'adapter à tout utilisateur. La relation est à double sens.
4. Épargnons le temps de l'utilisateur. L'utilisateur ne doit pas passer du temps à trouver le logiciel dont il a besoin ni à apprendre le fonctionnement du système de classification plus que nécessaire. Le but est de trouver le logiciel, pas de devenir un spécialiste du classement.
5. Une distribution est un organisme en développement. Une distribution n'est pas un système figé. Elle évolue en permanence et les règles de classement des logiciels doivent pouvoir s'adapter à cette évolution.

Il est amusant de remarquer que ces lois qui peuvent donc s'appliquer aux logiciels d'une distribution fonctionnent également parfaitement avec les sitesVVeb.LeVVVVVV peut être comparé, en effet,à une gigantesque bibliothèque. Les moteurs de recherche les plus populaires actuellement, indépendamment de la méthode de tri des résultats, en sont encore à la recherche textuelle. Beaucoup d'utilisateurs remarquent ainsi que nous touchons déjà aux limites de ce type de recherche et l'utilisation des travaux de Ranganathan représente une solution. Reste à trouver comment mettre en oeuvre ces principes de classement à l'échelle planétaire, de manière multilingue et communautaire/collaborative.
Utilisant ces lois en guise d'axiomes, Ranganathan créa un système de classification adapté appelé « classification à facettes » dont la définition est : une classification à facettes est une méthode de classification utilisant des aspects, des propriétés et des caractéristiques clairement définis, mutuellement exclusifs et collectivement exhaustifs pour un sujet donné.Voilà qui n'est pas très clair.
En classification à facettes, nous avons plus qu'un jeu de catégories ou sections. Nous en avons un pour chaque aspect du logiciel. Chaque aspect ou facette du logiciel possède ainsi sa collection de catégorie. Cela va bien plus loin que le simple fait de classer un logiciel dans plusieurs catégories.Voici les facettes définies par Ranganathan pour classifier ses ouvrages (nos logiciels) :
P    : la Personnalité. C'est l'objet principal du logiciel, ce qu'il est. C'est la facette principale.
M : la Matière. La substance qui constitue le logiciel. En d'autres termes, de quoi il est fait.
E    : l'Énergie. L'opération en relation avec le logiciel. Ce que l'on peut faire avec.
S : l'eSpace. La couverture géographique du logiciel. Cette facette ne s'applique pas vraiment à un logiciel, mais on peut résumer en disant qu'elle décrit où nous utilisons le logiciel (même si la réponse est toujours la même).
T : le Temps. La période chronologique. Cette facette s'applique également difficilement aux logiciels. Ceci pourrait, dans Debian, être en rapport avec le moment où le logiciel est prêt à être utilisé.
L'enchaînement de ces facettes est dite «PMEST», en rapport avec les lettres qui identifient les noms des facettes (c'est plus évident en anglais : Personality, Matter, Energy, Space,Time).
Enrico Zini a donc utilisé PMEST pour créer un système de classement appelé DebTags.Voici comment Enrico décrit la manière dont PMEST est utilisé dans son système :
•    «Le paquet comprend un programme qui peut utiliser des informations qui ne sont pas stockées localement sur la machine» Est-ce que l'enregistrement de ces informations est l'objet principal du programme ? Si c'est le cas, la Personnalité du programme doit être classifiée dans une catégorie en relation avec le réseau. Sinon, c'est l'Energie du programme qui est classifiée dans une telle catégorie.
•    Le paquet contient du code qui utilise l'appel système socket( ). Ceci concerne la facette Matière du paquet, la technologie qu'il utilise et les fonctions qu'il met en oeuvre.
•    Le paquet analyse des journaux d'un pare-feu. Ceci implique que la Personnalité et l'Energie du programme sont en relation avec le réseau mais pas la Matière. Si on regarde de près, le programme ne fait que parcourir des données au format texte.
(D STRUCTURE DE DEBTAGS
Enrico Zini est parti de PMEST mais a élargi le nombre de facettes puisque,justement PMEST est un concept destiné à pouvoir être étendu (cinquième loi de Ranganathan). L'implémentation de DebTags utilise donc :
•    «Facets» : les facettes. Ce sont les différents aspects étudiés des paquets. On retrouve la liste des facettes avec grep "Facet: " /var/lib/debtags/vocabulary ou debtags tagcat I grep "Facet". On y retrouve des facettes «interface», «works-with», «made-of» ou encore «protocol».
SHIYALI RAMAMRITA RANGANATHAN
Shiyali Ramamrita Ranganathan (1892-1972) était un mathématicien et un bibliothécaire indien. Il est principalement connu pour ses travaux sur le catalogage et la classification. Il est célèbre en tant qu'inventeur de la classification à facettes et pour avoir édicté les cinq lois de Ranganathan :
I. Les livres sont faits pour être utilisés
2.A chaque lecteur son livre 3.A chaque livre son lecteur
4. Épargnons le temps du lecteur
5. Une bibliothèque est un organisme en développement
Ranganathan était considéré comme une « bête de travail » à un niveau pathologique (Workaholic en anglais). Comme le précise Wikipédia, un workaholic (de l'anglais work, travail, et du suffixe -holic) est une personne dépendant au travail ou accro au travail, à un degré qui relève de la dépendance compulsive ou névrotique. Il s'agit d'une réelle maladie particulièrement répandue au Japon, où l'on a même inventé un mot pour désigner le décès qui peut en découler : Karoshi.

EBTAGS : DES ÉTIQUETTES SUR LES PAQUETS
PAQUETS
•    «Tags» : les étiquettes. Ce sont les catégories permettant de classifier les paquets dans chaque facette. debtags tagcat permet de lister les tags qui apparaissent sous la forme du couple facette::catégorie. La catégorie est un mot anglais qui ne s'applique donc que dans la facette concernée.
•    «Vocabulary» :le lexique (la traduction en «vocabulaire» ne s'applique pas correctement ici). C'est le lieu de stockage des facettes et de tags. Le lexique contient la liste des facettes et des tags, une description pour chacun d'eux, la nature de la facette, et des informations de gestion (état). Le lexique est stocké dans un dépôt SVN et copié sur votre système lors d'un debtags update.Vous pouvez avoir un aperçu de son contenu en utilisant la commande grep-dctrl -FFacet -r . /var/1 i b/debtags/vocabul ary. Le lexique n'est pas figé et peut faire l'objet d'ajouts et de changements. Sa gestion est plus ou moins ouverte permettant ainsi à chacun de proposer des changements.
•    «Tag Database» :C'est le coeur du système. Là où sont stockés les tags pour chaque paquet. Là encore, cette base de données est mise à jour avec debtags update et stockée localement (/var/1 ib/debtags/package-tags).
p UTILISATION DE DEBTAGS
A présent que vous connaissez les tenants et les aboutissants du système, il est temps d'en faire usage. Commencez donc par installer le paquet debtags qui vous fournira la commande du même nom. La première étape est sans doute de voir à quoi ressemble la mise en oeuvre des tags. Pour cela, utilisez l'action show en précisant un ou plusieurs noms de paquets
denis@raven:- % debtags show vim
Name: vin
Priority: flot available
Section: editors
[...]
This package contain a version of vim compiled with a rather standard set of features. See the other vim-* packages if you need more (or less). Tags: devel::editor, interface::text-mode,
uitoolkit::ncurses, use::editing, works-with:dext
Cinq tags sont définis
devel ::editor :devel est une facette Energie, ce qu'on peut faire avec le logiciel, ici de l'édition pour le développement. interface: :text-mode : La facette est une Personnalité qui caractérise son utilisation, une interface en mode texte. ui tool kit: :ncurses :Vim est composé de Matière utilisant un toolkit d'interface ncurses. use: :edi ti ng : Encore une facette Personnalité qui indique à quoi sert le paquet, l'édition. works-with::text : Une autre facette Energie qui nous indique ce que manipule le programme dans le paquet, le texte.
Passons à la recherche. Nous allons considérer que Vim n'est pas un bon choix pour nous (c'est une fiction bien sûr) et décidons de chercher quelque chose qui nous conviendra mieux. Nous voulons un éditeur de texte, lié au développement d'applications et ayant une interface en mode texte.Aussi nous utilisons
% debtags search 'devel::editor &&
interface::text-mode && works-with::text'
[...]
vin - Vi IMproved - enhanced vi editor
[...]
elvis-tiny - Tiny vi compatible editor for the base system
nvi - 4.48S0 re-implementation of vi
vile - VI Like Emacs - vi work-alike
[...]
jed - editor for programmers (textmode version)
[...]
lpe - Lightweight Programmer's Editor
mped - Minimum Profit, a programmer's text editor
xemacs21-bin - highly customizable text editor
[...]
Nous n'avons que l'embarras du choix. DebTags n'est pas en mesure de prendre en compte l'aspect personnel des préférences de l'utilisateur. Il faut donc s'en tenir au descriptif des paquets et aux essais pour cela.
Poussons plus loin dans la recherche et imaginons qu'en fait vous ne vouliez pas un éditeur en mode console, mais autre chose.Vous pourriez, par exemple, rechercher ce qui fonctionne sous X. Pour cela, nous devons trouver le tag qui convient. Comme debtags est bien fait, il propose un système de recherche dans les tags. N'oubliez pas la quatrième loi de Ranganathan : «Épargnons le temps de l'utilisateur»