APT, DPKG et paquets Debian

Introduction

Cette page s'adresse principalement à ceux qui, découvrant Debian ou une distribution dérivée, souhaitent acquérir facilement et rapidement quelques informations nécessaires pour "bien" gérer leurs paquets Debian et ceci notamment à travers les programmes apt et dpkg. Elle peut donc également intéresser en partie tous ceux qui, bien que n'utilisant pas Debian, souhaitent utiliser ces mêmes programmes pour gérer leurs paquets.

Aucune connaissance spécifique préalable n'est réellement nécessaire pour aborder les informations contenues ci-dessous qui, partant de quelques généralités sur Debian et ses paquets, vous conduiront jusqu'à la compilation de ses paquets sources en passant par la gestion de ses paquets binaires. De nombreuses lignes de commandes sont proposées, nous y distinguerons celles qui peuvent être effectuées en tant qu'utilisateur, précédées d'un $, de celles qui doivent être effectuées en tant que root, précédées d'un #.

Debian : distributions et paquets

Quelques points très généraux concernant Debian, ses "distributions" (ou versions) et ses paquets, sont à connaître si vous souhaitez comprendre comment fonctionne le système de gestion des paquets et, par exemple, la configuration de apt. Les voici brièvement présentés.

Les différentes versions de la distribution

Il existe en permanence trois "distributions" Debian : stable, testing et unstable. Chacune de ces distributions porte un nom mais, mis à part pour l'unstable où ceci est sans conséquence, il ne faut pas confondre la distribution et son nom. A ce jour, la stable est la Woody, la testing est la Sarge, quant à l'unstable elle se nomme toujours Sid (pour Still In Development).

La distribution stable est la distribution officielle de Debian, c'est elle qui est recommandée notamment pour un usage professionnel. Les seules modifications qu'elle subit au cours de son existence sont des corrections de bugs et de trous de sécurité. Elle est la seule à être officiellement suivie par l'équipe de sécurité de Debian. La distribution testing représente la future distribution stable. Plus à jour que cette dernière (notamment quand celle-ci arrive en fin de vie) elle permet, hormis l'aspect sécurité, de bénéficier de la qualité et de tous les avantages du système de gestion des paquets Debian. La distribution testing peut être recommandée pour un usage personnel. La distribution unstable (pas vraiment instable par ailleurs) est constituée des paquets à l'essai avant d'être admis en testing. La plus à jour de toutes, elle souffre cependant parfois de ruptures dans le système de gestion des paquets. L'unstable s'adresse donc plutôt aux développeurs ou à ceux qui veulent être à la pointe quitte à perdre un peu en facilité d'utilisation.

Les grandes catégories de paquets

Licence et sources

Au sein de ces distributions, les paquets sont répartis en trois grandes catégories principalement selon les licences mises en jeu : main, non-free et contrib. Les paquets main sont libres et représentent seuls la distribution officielle, non seulement sa base mais encore le gros des troupes. Les paquets non-free sont non-libres (pour simplifier un peu) alors que les paquets contrib sont libres mais dépendent de paquets non-libres. Autrement dit, quand vous utilisez une distribution Debian (stable, testing ou unstable), le plus souvent vous n'utiliserez soit que des paquets main soit des paquets des trois catégories. C'est votre choix.

Outre la classification en trois grandes catégories dont nous venons de parler, deux divisions binaires sont à considérer au sein des paquets Debian. La première concerne les paquets libres parmi lesquels il faut distinguer les paquets sources (les deb-src) qui sont à compiler, des paquets précompilés ou binaires (les .deb). Pour simplifier nous pouvons dire qu'à chaque source correspond un binaire ou parfois plusieurs binaires obtenus avec des options de compilation différentes. La seconde division concerne les paquets us et non-us ; ces derniers étant simplement ceux qui ne peuvent être exportés depuis un serveur situé aux USA.

Catégories de paquets et dépendances

On peut enfin aussi trouver d'autres classifications des paquets comme leur niveau de priorité ou la section à laquelle ils appartiennent. Les niveaux de priorité vont de required (requis) à extra, en passant par important, standard et optionnal (optionnel). Les paquets requis sont nécessaires au fonctionnement de votre distribution et ne doivent pas être supprimés, c'est le cas par exemple de dpkg. La suppression de paquets importants risquerait de compromettre la santé de votre système, comme c'est le cas de apt. La priorité des paquets va ainsi décroissant jusqu'à extra ; les choix faits dans les dernières catégories relevant plus de l'utilisateur que des nécessités du système. D'autre part, les différentes sections auxquelles les paquets appartiennent sont par exemple : admin, base, devel, misc, net... mais cette dernière distinction est moins utile pour notre propos.

Comme parler d'un paquet de façon isolée n'a pas toujours beaucoup de sens, nous pouvons de plus distinguer six degrés de liaison entre paquets : depends, recommends, suggests, conflicts, replaces et provides. Les paquets depends sont ce que l'on appelle généralement les dépendances d'un paquet et sont donc obligatoires ; les paquets recommends sont recommandés pour accompagner un autre paquet ; les paquets suggests sont suggérés en complément. Notez la gradation entre "suggérer" et "recommander". Des paquets conflits sont en conflit et ne peuvent donc pas être installés simultanément ; un paquet replaces remplace certains fichiers d'un autre paquet par les siens ; un paquet provides procure un autre paquet.

Conventions de nommage

Signalons pour en terminer que le nom d'un paquet Debian suit toujours cette structure:

comme par exemple cmatrix_1.2a-2_i386.deb dont nous allons bientôt parler plus en détails.

Exploration d'un paquet .deb

Si vous souhaitez réaliser les commandes décrites ici, créez un nouveau répertoire ($ mkdir reptmp), entrez dans ce répertoire ($ cd reptmp), et placez-y l'archive cmatrix_1.2a-2_i386.deb comme décrit ci-dessous. Vous pourrez à la fin tout effacer en supprimant simplement le répertoire ($ rm -rf reptmp). Comme indiqué, faites le tout en tant que simple utilisateur.

Nous allons maintenant explorer un paquet debian, cmatrix_1.2a-2_i386.deb, à l'aide d'outils standards et donc disponibles sur toutes les distributions. Ceci nous permettra de mieux comprendre ensuite le fonctionnement des outils de gestion des paquets tels que apt et dpkg. Donc, si vous le souhaitez, vous pouvez télécharger cmatrix_1.2a-2_i386.deb (sous Debian apt-get install -d cmatrix le placera en /var/cache/apt/archives/ sans l'installer) et utiliser les commandes proposées ci-dessous quelle que soit votre distribution.

Un paquet debian est une archive ar (et non tar), c'est donc avec cette commande que nous allons tout d'abord en afficher le contenu.

Nous voyons que ce paquet, comme tout paquet Debian, contient à ce premier niveau trois fichiers : un fichier texte debian-binary et deux archives : control.tar.gz et data.tar.gz. Afin de poursuivre nous allons maintenant extraire le contenu de l'archive ar.

Ceci fait nous pouvons facilement connaître le contenu de chacun de ces trois fichiers. Un $ cat debian-binary nous renvoie seulement 2.0. Ceci correspond à la version du format de fichier .deb utilisée. A ma connaissance seul ce format 2.0 est actuellement en cours. Examinons maintenant le contenu de l'archive data.tar.gz.

Comme son nom l'indique cette archive contient les données, autrement dit les fichiers qui seront installés sur votre disque. Nous retrouvons ici sans peine de la documentation, une page man, des fontes, une entrée pour le menu Debian et enfin l'exécutable cmatrix. Si vous le souhaitez vous pouvez tester dès lors cet exécutable sans réellement l'installer. Pour cela entrez : $ tar -zxvf data.tar.gz ./usr/bin/cmatrix Un répertoire usr/bin/ contenant le fichier cmatrix a été créé dans le répertoire courant. Sans changer de répertoire, entrez : $ usr/bin/cmatrix La Matrice devrait s'afficher sur votre (x)terminal, appuyez sur Q pour quitter. Mais peut-être cela n'a-t-il pas fonctionné ? Un problème de dépendances ? Pour le savoir nous pourrions utiliser la commande ldd mais nous allons plutôt explorer le contenu de l'archive control.tar.gz dont nous pouvons supposer qu'elle contient des informations permettant le contrôle de l'installation ou de la désinstallation du paquet.

Cette archive ne contient que quatre fichiers : postinst, postrm, md5sum et control. Le fichier postinst est un script bash de post-installation, c'est-à-dire effectué en fin d'installation, après que l'archive data.tar.gz ait été désarchivée. Le fichier postrm est aussi un script bash mais de post-déinstallation, c'est-à-dire effectué en fin de désinstallation, sans doute après que les fichiers de data aient été supprimés. Bien qu'ils ne figurent pas ici, on peut aussi trouver dans une archive de contrôle un script preinst et un script prerm dont je vous laisse deviner l'utilisation. Pour ce qui est des deux autres fichiers présents ici, md5sums contient les sommes de contrôle md5 nécessaires pour la vérification de l'intégrité des fichiers du paquet et control contient de précieuses informations sur le paquet. Extrayons puis affichons le contenu de ce dernier fichier.

Outre diverses informations (section misc ou divers, priorité optionnelle) nous trouvons une ligne Depends qui nous permet de répondre à la question que nous nous posions précédemment : libc6 (>= 2.3.2.ds1-4) et libncurses5 (>= 5.4-1) constituent les dépendances de notre paquet. De plus il est recommandé d'installer le paquet console-tools ; le paquet cmatrix-xfont étant lui simplement suggéré. Voilà nous avons aperçu toutes ces notions dans la partie [#debian Debian : distributions et paquets] ; nous n'en dirons pas plus sur le sujet pour l'instant, mais nous nous réfèrerons par la suite à tout ce que nous venons de découvrir ainsi.

Apt, dpkg et la gestion des paquets

Apt et dpkg sont les deux principaux outils de gestion des paquets sous Debian en ligne de commande. Les mots apt, dpkg et gestion sont ici à prendre au sens large. Ce que nous entendons par gestion concerne aussi bien l'installation, la désinstallation que les multiples informations que l'on peut recueillir sur les paquets ou encore les questions de dépendances, conflits, mises à jour... Ces différents thèmes nous conduirons à parler de apt et de sa famille comme apt-get, apt-cache, apt-file mais aussi de la famille de dpkg comme dpkg-deb ou dpkg-reconfigure. De façon générale cette partie étant structurée par thèmes (et non par types de commandes) nous donnerons ici la préférence à apt qui est plus abouti que dpkg, n'utilisant ce dernier que lorsqu'il s'avère nécessaire ou apporte quelque chose de plus. Enfin si vous êtes allergiques aux lignes de commandes, la partie suivante [#interf Interfaces textes et graphiques] vous propose une brève présentation de quelques programmes.

Configurer et gérer apt

Une façon simple et courante de faire connaissance avec une distribution consiste à télécharger l'iso de son premier CD d'installation, puis à essayer de l'installer. Si vous procédez ainsi avec Debian et sa version stable, à la fin de l'installation vous devriez posséder un fichier /etc/apt/sources.list ressemblant à ceci (mes CDs datent un peu mais cela ne change rien à l'affaire, je pense. Notez que bien qu'il s'agisse d'une version stable Woody le mot unstable figure dans le fichier... je ne sais pourquoi).

Ce fichier sources.list, comme son nom l'indique, sert à préciser à apt où il peut aller chercher les listes de paquets et paquets pour les installations et les mises à jour par exemple. C'est un fichier fondamental pour la configuration de apt. Ici il ne comporte pour l'instant que deux lignes, la première correspondant au premier CD, la seconde aux mises à jour de sécurité puisque nous sommes en stable. Ces mises à jour nécessitent bien sûr une connexion internet (si nous n'en avions pas cette ligne serait commentée, avec un # au début), mais supposons pour l'instant que vous possédiez une connexion rtc et deux autres CDs d'installation et que donc vous souhaitiez les ajouter. Pour cela entrez simplement : # apt-cdrom add

Apt s'occupe de tout, démonte le lecteur CD, l'ouvre, vous demande d'insérer le CD, le monte, fait sa petite cuisine, démonte puis vous rend la main. Si cela ne fonctionnait pas plusieurs causes sont possibles, d'un mauvais point de montage du répertoire /cdrom/ dans votre fichier /etc/fstab à un CD défectueux... Je ne peux savoir. Admettons que tout fonctionne et que vous procédiez ainsi pour vos deux autres CDs, votre fichier sources.list ressemble maintenant à ceci.

Voilà. Si on peut envisager d'utiliser une version stable avec un jeu de CDs et une connexion rtc, l'utilisation d'une version testing ou unstable est difficilement envisageable sans une connexion haut débit. Voyons donc maintenant comment indiquer à apt d'aller chercher listes et paquets sur les serveurs Debian. S'il n'est guère possible d'ajouter une source CD en éditant directement le fichier sources.list, c'est au contraire en éditant celui-ci que l'on ajoute habituellement une source réseau. Voici le sources.list du PC où est rédigé cet article.

Ce fichier sources.list, assez minimal, ne comporte que quatre lignes. Les deux dernières (deb-src) concernent les paquets sources Debian, nous verrons cela dans la partie [#compil Compiler un paquet deb-src]. Les deux premières concernent les binaires (.deb) et leur lecture permet de comprendre aisément que ce PC utilise les paquets main "us" (us n'est pas spécifié, première ligne) et non-us (seconde ligne) de la distribution testing. Si tous les paquets étaient utilisés "contrib" et "non-free" figureraient après "main" ; si une autre distribution était utilisée (stable ou unstable) ceci figurerait à la place de "testing". Donc, pour un dernier exemple, le fichier sources.list internet correspondant (à peu près, les paquets non-free en plus... disons qui le remplacerait avantageusement) au fichier CD que nous avions précédemment pour une stable serait celui-ci.

Il est important de penser à mettre à jour les listes des paquets à chaque fois que l'on modifie le fichier sources.list. De plus si on utilise des sources internet, il faut aussi penser à les actualiser à chaque fois que l'on souhaite installer de nouveaux paquets, mettre à jour ses paquets ou même rechercher des informations. Ceci se fait très simplement en une ligne de commande : # apt-get update

Que se passe-t-il alors ? Apt va récupérer sur les serveurs les fichiers packages.gz décrivant les paquets disponibles. Les informations sont alors entreposées dans les fichiers du répertoire /var/lib/apt/lists/ de votre distribution. Nous reparlerons de ces fichiers un peu plus loin. Un autre répertoire à connaître est /var/cache/apt/archives/ ; c'est en effet dans celui-ci que apt entrepose tous les fichiers binaires qu'il récupère sur les serveurs lors d'une installation ou d'une mise à jour. Notons accessoirement que l'on trouve aussi dans ce répertoire un répertoire partial/ contenant, au cas où, les paquets qui n'ont pu être que partiellement téléchargés. Rappelons au passage que pour connaître la taille occupée par ces archives, il vous suffit d'entrer : $ du -sh /var/cache/apt/archives/

Faut-il maintenant préciser que, lors d'installations réseaux puis de mises à jour, la taille du répertoire archives/ a tendance à fortement augmenter ? Heureusement ce répertoire est assez simple à gérer. La commande # apt-get clean en supprime tout simplement le contenu (sauf le fichier lock) ; mieux, si vous avez de la place, la commande # apt-get autoclean n'en supprime que les paquets devenus obsolètes. D'autre part, vous pouvez fort bien effacer "à la main" certains paquets (et donc en conserver d'autres)... ceci ne gènera nullement le bon fonctionnement de apt.

Une petite question pour clore cette partie. Nous avons vu que si la distribution unstable s'appelle toujours Sid, les autres distributions portent un nom changeant. A ce jour, où la testing se nomme Sarge, cela modifierait-il quelque chose si au lieu de "testing" il était indiqué "sarge" dans le fichier sources.list ? Non pour ce qui est de ce jour, mais oui pour ce qui est de l'avenir. En effet le jour où la Sarge passera en stable, si sarge était écrit dans ce fichier nous passerions alors en stable ; alors que si testing y est écrit, nous resterons en testing (et donc passerons en ?).

Il y aurait sûrement encore beaucoup à dire concernant la configuration et la gestion de apt comme parler du fichier /etc/apt/apt.conf ou du répertoire /etc/apt/apt.conf.d/ permettant de modifier le comportement par défaut de apt ; de l'utilisation d'une distributions mixte (testing / unstable par exemple) ou encore d'un proxy... mais n'étant ni omniscient ni omnipotent je m'en tiendrai là. Une dernière chose tout de même, si vous ne parvenez pas à configurer apt manuellement, essayez donc la commande # apt-setup qui permet de nombreuses configurations et dont voici une petite copie du premier écran.

S'informer sur les paquets

Afin d'éviter d'inutiles répétitions au sein de cette page, je ne donnerai parfois dans cette partie que des explications théoriques et vous renverrai le cas échéant aux autres parties pour les exemples pratiques.

Nous avons vu dans la partie [#explo Exploration d'un paquet .deb] comment nous pouvions à l'aide de commandes standards interroger un paquet téléchargé. Il existe bien sûr des commandes apt et dpkg permettant de faire de même plus facilement ; il existe aussi des commandes permettant de faire bien plus. Si vous souhaitez pouvoir effectuer certaines des interrogations présentées ci-dessous sur des paquets non-installés et non-téléchargés, mais figurant dans le sources.list, vous devrez tout d'abord installer apt-file puis le mettre à jour. Ceci se fait en deux lignes de commandes.

Maintenant que tout est prêt, voici un petit jeu de questions - réponses.

Quels sont les paquets installés et bien configurés ?
La commande dpkg -l permet de lister toutes sortes de paquets comme ceux non-installés, installés ou encore ceux désinstallés sous certaines conditions. Nous l'utilisons ci-desous avec différents filtres grep afin de répondre à différentes questions. Les lignes correspondant aux paquets bien installés et configurés commencent par "ii", pour les lister nous entrons alors : $ dpkg -l | grep ^ii | less

La liste de ces commandes installées rique d'être assez longue. Aussi si vous voulez simplement connaître le nombre de paquets ainsi listés, utilisez : $ dpkg -l | grep ^ii | wc -l

Quels sont les paquets "autres" (que les précédents) ?
Pour répondre à cette question, il nous suffit de demander à grep d'inverser le filtre utilisé précédemment. Nous obtenons ainsi toutes les lignes ne commençant pas par "ii" sans toutefois inclure les paquets qui n'ont "jamais été installés" et dont, comme nous le verrons plus bas, les lignes commencent par "un" (copie d'écran incomplète).

Certaines lignes, ici relatives au noyau (kernel), commencent par "hi" et concernent des paquets installés puis marqués comme à conserver (voir [#ajour Mettre à jour sa distribution]). D'autres lignes, ici relatives à xemacs, commencent par "rc", il s'agit de paquets qui ont été supprimés mais restent configurés (voir [#adesinst Désinstaller des paquets]). Lors de vos essais, si vous procédez à d'autres types d'interrogations avec dpkg -l, peut-être rencontrerez-vous aussi de très nombreuses lignes commençant par "un" ; il s'agit de paquets non-installés non-configurés. Si vous souhaitez absolument à en voir la liste, puis à les compter, entrez ces deux commandes : $ dpkg -l "*" | grep ^un | more puis $ dpkg -l "*" | grep ^un | wc -l

Il est possible de faire bien d'autres interrogations avec dpkg -l mais celles-ci ne nous apporteraient que peu par rapport à ce qui suit. Une astuce tout de même. Par défaut dpkg -l sort ses résultats sur 80 colonnes, il s'en suit que ceux-ci sont souvent tronqués (noms des paquets, définitions). Pour remédier à cela il suffit de faire précéder cette commande par la définition de variable COLUMNS=132. Par exemple : $ COLUMNS=132 dpkg -l | grep -v ^ii

Quel paquet pour faire ceci ou cela ?
Nous sommes souvent bien prosaïques. Nous souhaitons par exemple installer un économiseur d'écran, nous nous demandons alors desquels nous pouvons facilement disposer pour faire notre choix et peu importe le reste. La commande apt-cache permet de répondre assez facilement (mais pas toujours parfaitement) à des questions de ce type, il suffit pour cela d'employer l'option search et quelques options et/ou mots clés. Donc par exemple (copie d'écran incomplète):

Apt est allé chercher le mot clé proposé dans les noms des paquets ainsi que dans leurs descriptions dans les fichiers du répertoire /var/lib/apt/lists/ Ceci donnera parfois bien plus de réponses que vous ne le souhaiteriez. Dans ce cas vous pouvez affiner la recherche en entrant plusieurs mots clés (ou en les modifiants). Ainsi précisons que nous souhaitons un économiseur pour nos consoles:

Maintenant que nous n'avons que peu de réponses, nous pouvons demander à apt d'afficher en même temps les informations sur les paquets sélectionnés en utilisant l'option "-f" : $ apt-cache search -f screensaver console Ceci nous permet de comparer facilement les différents candidats... Nous parlerons plus amplement de ces informations un peu plus bas dans : Qui est ce paquet ? Enfin notons une autre possibilité pour mieux cerner les réponses obtenues : celle-ci consiste à demander à apt de ne chercher que dans les noms des paquets. Cette méthode suppose cependant soit que le nom du paquet ait un rapport direct avec la fonction que nous recherchons, soit que nous connaissions déjà partiellement le nom d'un paquet recherché correspondant. Comparez par exemple les différences des résultats suivants (sorties d'écran incomplètes).

La méthode de recherche est loin d'être performante à 100%. Souvent il vous faudra tâtonner avec les mots clés et options avant de trouver ce que vous cherchiez... Vous découvrirez aussi sans doute ainsi des paquets dont vous ne soupçonniez pas l'existence.

Dans quel paquet se trouve ce fichier ?
Deux cas de figure sont ici possibles. Soit vous possédez un fichier et vous vous demandez de quel paquet il provient, soit vous aimeriez installer un fichier mais vous ne savez pas dans quel paquet le trouver. Nous venons par exemple d'utiliser la commande apt-cache, mais de quel paquet vient-elle ? Pour le savoir il suffit d'entrer:

Celle-ci provient du paquet apt, tout simplement (alors que la commande apt-file provient du paquet apt-file et doit donc être installée en plus). Nous avons ici utilisé le chemin complet de la commande afin de bien préciser quel fichier nous intéressait. En moins précis vous pouvez essayer : $ dpkg -S apt-cache afin de comparer. Apt-file permet de faire ce même type de recherches sur des paquets qui n'ont pas été installés mais sont accessibles via le fichier sources.list. Ainsi vous savez que, pour compiler un paquet source Debian, la commande dpkg-buildpackage est nécessaire, mais vous ne l'avez pas. Pour savoir dans quel paquet elle figure, entrez:

La commande recherchée figure dans deux paquets : dpkg-cross et dpkg-dev. En examinant ces deux paquets vous découvririez que dpkg-croos, comme son nom le suggère, est uniquement nécessaire pour effectuer des compilations croisées et que dpkg-deb, qui fait d'ailleurs partie de ses dépendances, vous suffira tant que vous ne souhaitez que compiler pour votre architecture. Mais peut-être ne savez-vous pas comment recueillir ces informations ? Justement nous allions en parler.

Qui est ce paquet ?
Pour répondre à cette question, nous allons considérer trois possibilités : le paquet est installé ; le paquet n'est ni téléchargé ni installé mais figure dans le sources.list et le paquet a été récupéré quelque part (éventuellement hors du sources.list, CD, serveur...) et n'est pas encore installé. Commençons par ce dernier cas car il est le plus proche de ce que nous avons vu dans la partie [#explo Exploration d'un paquet .deb]. Cette fois cependant nous n'utiliserons pas des outils standards, mais les outils Debian et ce sera bien plus simple et rapide. Pour obtenir les informations générales sur le paquet il suffit d'utiliser la commande dpkg-deb -I nom_paquet.deb. Pour reprendre notre exemple:

Comme nous le voyons, d'après ce que nous avons appris, cette commande affiche le contenu du fichier debian-binary, les noms des fichiers présents dans l'archive control.tar.gz ainsi que le contenu du fichier control de cette archive. Affichons maintenant les données contenues dans le paquet à l'aide de la commande dpkg-deb -c nom_paquet.deb Pour reprendre notre exemple:

Cette fois c'est le contenu de l'archive data.tar.gz qui nous est présenté (comme avec tar -ztf et l'option "-v" que nous n'avions pas ajoutée lors de notre exploration standard). Notez que si vous préférez vous pouvez entrer dpkg -I nom_paquet.deb et dpkg -c nom_paquet.deb ; dpkg appellera alors pour vous dpkg-deb. Si ce dernier utilise directement les informations contenues dans le paquet pour afficher ses résultats, ceci n'est pas le cas des commandes dpkg et apt que nous allons voir maintenant qui elles utilisent des fichiers de données placés respectivement en /var/lib/dpkg/ et /var/lib/apt/.

Si vous souhaitez explorer un paquet qui est installé, que vous possédiez ou non son archive, vous pouvez utiliser la commande dpkg -p nom_paquet pour afficher ses informations et la commande dpkg -L nom_paquet pour afficher ses fichiers. Par exemple donc : $ dpkg -p apt puis $ dpkg -L apt | more

Enfin si le paquet n'est ni téléchargé, ni installé mais figure dans le sources.list, vous pouvez utiliser la commande apt-cache show nom_paquet pour afficher ses informations et la commande apt-file list nom_paquet pour afficher ses fichiers. Par exemple : $ apt-cache show dpkg-dev dpkg-cross | less puis $ apt-file list dpkg-dev

Je ne fais pas de copies des sorties d'écran pour toutes ces dernières commandes et vous laisse le soin de les examiner par vous-mêmes si vous le souhaitez. Enfin pour observer plus particulièrement le jeu des dépendances d'un paquet la commande apt-cache depends nom_paquet s'avère une aide précieuse. Par exemple:

Pour ce qui est de la compréhension des lignes précédentes et des termes Depends, Suggests ou Replaces, merci de vous référer à la partie [#debian Debian : distributions et paquets].

Installer des paquets

La commande apt-get install nom(s)_paquet(s) est-il bien nécessaire de la présenter ? Nous la retrouvons partout et l'avons déjà utilisée dans cette page ; c'est elle qui permet d'installer un paquet à partir du fichier sources.list. Cette commande gère les dépendances et les conflits. Si seul le paquet demandé doit être installé elle procèdera à son installation sans rien vous demander, par contre si d'autres paquets doivent être installés (dépendances) ou supprimés (conflits) elle vous demandera confirmation avant d'opérer.

Il est possible d'utiliser des caractères comme ? ou * et des expressions plus complexes pour désigner des groupes de paquets. Soyez tout de même prudents, l'option "-s" vous permet par exemple de simuler ce qui devrait être réalisé. Deux autres options sont aussi bien utiles. L'option "-y" répond oui pour vous à toutes les questions triviales mais ne répond pas aux questions qui pourraient mettre la santé de votre système en jeu. L'option "-d" permet dans le cas d'une installation via internet de seulement télécharger les paquets qui sont alors mis en attente en /var/cache/apt/archives/ pour une installation ultérieure. Voyons à titre illustratif une simulation de l'installation du serveur web apache.

Quatre paquets seront installés puis configurés, le paquet demandé, apache, et trois dépendances : apache-common, apache-utils et mime-support. Notons également que trois suggestions d'installation sont faites : apache-doc, apache-ssl et apache-perl. Autrement dit le mainteneur de ce paquet pense que ces paquets pourraient bien vous être utiles mais, comme ils ne sont pas absolument nécessaires, il vous les suggère simplement. Enfin quatre paquets apparaissent comme non mis à jour... mais ceci n'a rien à voir avec l'opération que nous venons de demander.

Si vous souhaitez installer un paquet ne provenant pas de votre sources.list mais de "je ne sais où" (un CD, un site... ) mieux vaut d'abord l'inspecter soigneusement. Ensuite vous pourrez utiliser la commande dpkg pour l'installer : # dpkg -i nom_paquet.deb

Lors de leur installation certains paquets vous posent des questions concernant leur configuration et utilisent pour cela debconf. Si vous regrettez les choix faits à ce moment, il est toujours possible de revenir à ces questions de configuration en utilisant dpkg-reconfigure (sinon vous pouvez aussi toujours procéder à la main...). Debconf propose plusieurs interfaces possibles (dialog, readline, gnome, kde, editor...) mais aussi quatre niveaux de questions (critical, high, medium et low). Le niveau critical ne vous questionnera que si l'équilibre de votre système est en danger alors qu'à l'opposé le niveau low vous interrogera sur tout. Je pense qu'utiliser ce dernier niveau est une bonne chose. Les questions posées ne sont pas si nombreuses et, au pire, si comme moi vous ne savez que répondre à quelques questions, vous choisirez simplement les réponses proposées par défaut... ceci aura au moins l'avantage de vous montrer quelles questions il serait bon que vous vous posiez. Donc si vous le souhaitez, reconfigurez debconf : # dpkg-reconfigure debconf

Choisissez l'interface qui vous convient le mieux (je choisis dialog), lisez l'écran d'information puis choisissez le niveau low comme ci-dessus. Voilà c'est déjà fini. N'oubliez pas que vous pouvez utiliser ainsi dpkg-reconfigure pour tous les paquets possédant une telle procédure d'installation, un exemple fréquent étant : # dpkg-reconfigure xserver-xfree86

Mettre à jour sa distribution

A peine une distribution installée qu'il faut bien souvent penser à la mettre à jour, bien qu'en fait avoir "la dernière version possible" de tel ou tel programme ne soit pas vraiment un objectif majeur en soi. Sous Debian avec apt ces mises à jour se font avec une facilité déconcertante. Bien sûr rappellons tout de même que la première chose à faire est, comme avant une installation, d'actualiser la liste des paquets (# apt-get update). Ceci fait une petite commande se charge de presque tout : # apt-get upgrade

Avec une version stable les mises à jour portent sur des corrections de bugs et de trous de sécurité des paquets et sont, si importantes, peu nombreuses. Avec les versions testing et unstables se sont presque quotidiennement de nouvelles versions des paquets installés qui sont proposées : une connexion haut débit est requise. Avant de procéder à une mise à jour, il est possible, comme avant une installation, de procéder à une simulation en utilisant l'option "-s". Simulons donc une mise à jour.

Ici un seul paquet serait actualisé, pcmcia-cs (daemon pour les cartes pcmcia), et quatre paquets qui pourraient être mis à jour seront conservés : kernel-headers-2.4.27-1, kernel-headers-2.4.27-1-686, kernel-image-2.4.27-1-686 et kernel-pcmcia-modules-2.4.27-1-686. Comme nous le voyons une mise à jour ne concerne donc pas toujours tous les paquets qui pourraient l'être. Nous allons en parler dans quelques lignes. Avant de procéder, la commande apt-show-versions -u vous permet de visualiser simplement quelles sont les versions des paquets qui sont ou pourraient être impliquées.

Nous constatons que les changements de versions à effectuer sont vraiment mineurs. Une fois la mise à jour réalisée avec # apt-get upgrade, quatre paquets du noyau ne seront toujours pas mis à jour, pourquoi ? Deux raisons sont possibles : soit ils ont été marqués par nous-même "hold" c'est-à-dire à conserver ; soit leur mise à jour demanderait la suppression (conflits) ou l'ajout (dépendances) de nouveaux paquets (éventuellement les deux mais dans ce cas ce serait plutôt la première raison qui primerait). En effet la commande apt-get upgrade ne retranche ni n'ajoute d'elle-même aucun paquet. Si ceci est nécessaire et que l'on veut procéder à la mise à jour, il faut utiliser la commande apt-get dist-upgrade. Essayons une simulation (nous avons mis à jour entre temps le paquet pcmcia-cs ).

Rien ne serait changé, les quatre paquets du noyau seraient conservés, ceci est dû au fait qu'ils ont été marqués hold, à conserver ; peut-être vous souvenez-vous à ce propos que ces paquets nous sont apparus comme "hi" dans [#ainfo S'informer sur les paquets] quand nous avons utilisé la commande dpkg -l | grep -v ^ii Afin de pourvoir être sûr de conserver ainsi certaines versions des paquets lors des mises à jour, voici comment il faut procéder. La commande dpkg --get-selections permet d'obtenir la liste de sélection des paquets qui sont tous marqués install, à installer, par défaut. Nous allons tout d'abord créer un fichier /etc/apt/selections en redirigeant la sortie de cette commande : # dpkg --get-selections > /etc/apt/selections

Vous devez maintenant éditer cette liste afin de remplacer les "install" des paquets que vous souhaitez conserver par des "hold". Vous pouvez utiliser l'éditeur nano qui est fort simple, mes lignes concernées ressemblent à ceci:

Les modifications effectuées et le fichier sauvegardé, vous devez indiquer à dpkg les nouvelles règles de sélection que vous venez de définir. Ceci se fait ainsi : # dpkg --set-selections <p /etc/apt/selections

Comme nous en verrons un exemple dans la partie [#compil Compiler un paquet deb-src], lorsque vous souhaitez juste marquer un seul ou peu de paquets, vous pouvez aussi procéder directement en ligne de commandes avec : echo "nom_paquet hold" | dpkg --set-selections. De même pour vérifier le statut d'un paquet de façon isolée, vous pouvez utiliser la commande dpkg -s nom_paquet | head -n 4

Bien sûr si vous ne souhaitez plus conserver un paquet lors des mises à jour, il suffit de procéder inversement en remplaçant hold par install. Si vous ne souhaitez pas faire ainsi, une autre possibilité consiste à utiliser l'option --ignore-hold soit avec upgrade soit avec dist-upgrade. Ceci donne une ligne de commande de ce type : # apt-get dist-upgrade --ignore-hold

Pour conclure, notez que seuls les paquets que vous avez vous-mêmes désignés comme à conserver doivent rester ainsi lorsque vous avez procédé à une mise à jour complète de votre distribution à l'aide des commandes apt-get upgrade et apt-get dist-upgrade. Nous retrouverons par ailleurs cette dernière commande, mais pour une autre utilisation, dans [#achange Changer de distribution].

Désinstaller des paquets

La commande apt-get remove nom(s)_paquet(s) qui permet de supprimer des paquets s'utilise de la même façon que la commande apt-get install nom(s)_paquet(s) qui, nous l'avons vu, permet de les installer. Certaines des options que nous avons alors rencontrées sont toujours d'actualité comme "-s" pour une simulation, ? ou * ou autres pour désigner des groupes de paquets, "-y" pour répondre oui aux questions triviales comme les demandes de confirmation de suppression sur des paquets non vitaux. Nul n'est toujours bien inspiré, aussi simulons une intention de désinstallation de apt.

La première chose à voir est le WARNING qui nous avertit clairement que nous risquons là de faire une grosse bêtise et donc de ne procéder que si nous sommes bien sûr de nous. En effet nous simulons ici la désinstallation d'un paquet dont le niveau de priorité est important. Certes nous ne procéderons pas à la réelle désinstallation de apt. Nous voyons d'autre part qu'outre le paquet demandé, apt, sept autres paquets seraient aussi supprimés car leur bon fonctionnement dépend de celui-ci. Ainsi de la même façon que apt-get install gère les dépendances, nous pouvons dire que apt-get remove gère les dépendances inverses.

Par défaut apt-get remove supprime les données des paquets mais pas leurs fichiers de configuration (quand ils existent), c'est pour cela que des paquets installés puis supprimés peuvent apparaître comme désinstallés mais configurés. Ainsi dans [#ainfo S'informer sur les paquets] avons nous vu certains paquets xemacs apparaître comme "rc" en utilisant la commande dpkg -l | grep -v ^ii

Si vous souhaitez également supprimer les fichiers de configuration liés à un paquet, il suffit d'ajouter l'option --purge ce qui donne : apt-get remove --purge nom_paquet. Mais même en procédant ainsi, après un certain nombre d'installations suivies de désinstallations, votre système comportera des fichiers, généralement des bibliothèques, devenus inutiles mais toujours là. Pour les trouver afin de les supprimer utilisez la commande : $ deborphan. Entrée telle quelle celle-ci ne recherche que dans les bibliothèques et affiche la liste des orphelines. Voici une petite commande bien utile pour faire automatiquement le ménage parmi celles-ci (notez l'utilisation de l'option "-y") : # deborphan | xargs apt-get remove --purge -y

Changer de distribution

Il ne s'agit ici que de changer de distribution ou version Debian. La première chose à savoir est que s'il est considéré comme facile d'upgrader, il est aussi considéré comme difficile, voir impossible, de downgrader. Par upgrader il faut comprendre passer de stable en testing ou unstable, ou bien de testing en unstable ; par downgrader il faut comprendre une tentative inverse. Ce n'est certes pas dans le cadre d'une utilisation normale le genre d'opérations que l'on effectue au quotidien... Je me contenterai donc ici de vous parler brièvement de mon expérience personnelle sans chercher à en tirer de quelconques généralités ou vérités, en espérant simplement qu'elle pourra vous être utile. Je ne parlerai d'ailleurs que d'upgrade, n'ayant jamais essayé de downgrader.

Maladresse, PC trop chatouilleux, malchance... les deux fois où j'ai essayé d'installer directement une distribution testing ou unstable, ceci s'est soldé par un échec. La première fois je n'eus pas de clavier dès le premier écran d'installation, la seconde fois j'eus un beau kernel panic dès le premier boot. Par contre à chaque fois que j'ai installé d'abord une base de distribution stable puis l'ai ensuite upgradée soit en testing soit en unstable, tout s'est passé à merveille.

Quand je souhaite être assuré du résultat, je procède donc maintenant toujours ainsi : j'installe une base texte minimale avec le premier CD de la distribution stable (en n'utilisant ni dselect ni tasksel... mais la procédure va bientôt changer avec le nouvel installateur), l'ensemble pèse au total bien moins de 100 Mo. Lors de cette installation, je n'effectue que quelques configurations généralement proposées par le programme comme le clavier, l'heure, le réseau : l'important étant de pouvoir se connecter aux serveurs d'une façon ou d'une autre. Ceci fait j'édite le fichier sources.list pour le faire correspondre à ce que je souhaite. Deux lignes suffisent amplement pour un premier temps comme:

Il ne manque plus que deux lignes de commandes et un peu de temps pour passer en testing ou unstable avant de pouvoir terminer l'installation et la configuration:

Interfaces textes et graphiques

Pour ceux que les lignes de commandes ennuient, ou qui simplement souhaitent essayer autre chose, voyons brièvement deux interfaces de gestion des paquets : aptitude en mode texte et synaptic en mode graphique.

Aptitude est une interface texte qui va remplacer, remplace déjà, dselect. Lancez aptitude en entrant son nom dans un terminal en tant que simple utilisateur ou à l'aide de votre menu "Debian / Apps / System /". Si les actions que vous demandez le nécessitent, ce programme vous proposera de lui-même de passer en root ou encore vous pourrez passer en root grâce au menu "Actions / Devenir administrateur". La copie d'écran ci-dessous, correspondant à une résolution standard de 80 colonnes fois 25 lignes, montre justement ce menu Actions ainsi que la définition du programme aptitude.

Pour débuter trois touches sont particulièrement intéressantes. La touche F10 permet d'ouvrir les menus que vous pouvez quitter avec la touche Echap (Esc). La touche ? donne un accès à l'aide que vous pouvez quitter avec la touche Entrée (Enter) ; à tout moment la touche Q vous permet de quitter le programme. Les principaux menus d'aptitude sont Actions, Défaire, Paquet, Rechercher, Options, Vues et Aide. Nous ne les décrirons pas ici, de nombreux raccourcis clavier permettent de plus de court-circuiter ces menus.

Comme toute interface texte un peu complexe aptitude requiert une petite période d'adaptation ; synaptic qui est une interface graphique semble plus facile à prendre en main. Normalement synaptic ne peut pas être appelé en tant qu'utilisateur depuis un terminal en entrant simplement $ /usr/sbin/synaptic ; ceci n'est pas une raison pour vous connecter directement en mode graphique en tant que root. La façon la plus simple de lancer synaptic est d'aller le chercher dans le menu "Debian / Apps / System /". Si vous ne possédez pas ce menu ou n'y trouvez pas synaptic, vous pouvez aussi entrer dans un xterminal la commande utilisée normalement par ce menu : $ /usr/sbin/su-to-root -X -c /usr/sbin/synaptic

Une première fenêtre s'ouvrira, vous demandant le mot de passe root puis, en même temps que synaptic, une seconde fenêtre de présentation (très) rapide. Les principaux menus de synaptic sont Fichier, Edition, Paquet, Catégories et Aide. De façon générale un clic gauche permet de faire une sélection, un clic droit d'obtenir un menu contextuel. Dans la copie d'écran ci-dessous, le paquet synaptic a été sélectionné parmi les paquets Administration système.

Il existe d'autres interfaces de gestion des paquets possibles comme dselect ou encore tasksel. Mais dselect est en fin de vie, comme nous l'avons vu aptitude le remplace ; quant à tasksel, il propose des sélections de paquets par (trop) grands thèmes comme "Environnement graphique de bureau" ou "Serveur web" ainsi qu'une entrée "Choix manuel des paquets" qui appelle aptitude... Considérons donc que la boucle est bouclée mais notez cependant que si tasksel nécessite aptitude, la réciproque n'est pas vraie.

Compiler un paquet debsrc

Nous avons vu dans la partie [#debian Debian : distributions et paquets] qu'il fallait distinguer les paquets sources (deb-src) des paquets précompilés ou binaires (.deb). Jusqu'à présent nous n'avons vraiment parlé que des paquets binaires, voyons donc maintenant comment compiler les paquets sources. Plusieurs méthodes sont possibles pour créer un paquet binaire à partir d'un paquet source. Seules les grandes lignes de l'une d'elles sont indiquées ici afin de vous permettre de faire vos premiers pas facilement.

La première fois vous devez tout d'abord installer deux paquets : dpkg-dev et fakeroot. Le paquet dpkg-dev est ici indispensable car il vous fournit notamment la commande dpkg-buildpackage comme nous l'avons vu dans [#ainfo S'informer sur les paquets]. Le paquet fakeroot est facultatif, il vous permettra simplement ici d'utiliser cette commande sans être root, ce qui est tout de même un avantage du point de vue sécurité. Donc : # apt-get install dpkg-dev fakeroot

Ceci fait, comme nous l'avons évoqué dans [#aconf Configurer et gérer apt], afin de pouvoir récupérer facilement des paquets sources, vous devez modifier votre fichier /etc/apt/sources.list afin d'y inclure deux lignes similaires à celles-ci (ici pour une distribution testing):

Enfin, comme après chaque modification de ce fichier, ou comme avant chaque nouvelle installation, une mise à jour des listes des paquets disponibles s'impose : # apt-get update

Les préparatifs généraux étant terminés, entrons dans le vif du sujet. Pour ce qui est de la compilation de ses paquets sources, Debian vous facilite bien la vie puisqu'il existe une commande apt-get build-dep permettant d'installer tout ce qui sera nécessaire à la compilation que vous souhaitez réaliser (hormis les commandes triviales comme gzip, tar... et hormis les sources du paquet). Donc si vous souhaitez compiler nom_paquet, entrez : # apt-get build-dep nom_paquet

Tout le nécessaire à la compilation de ce paquet étant installé, sauf ses sources, il vous faut maintenant les télécharger. Créez d'abord un répertoire de travail, placez-vous ensuite dans ce répertoire pour y télécharger les sources que vous souhaitez compiler. Notez que cette partie se fait en mode utilisateur.

Cette dernière commande télécharge dans le répertoire courant les trois fichiers nom_paquet.tar.gz, les sources ; nom_paquet.dsc, la description du paquet et nom_paquet.diff.gz, les modifications apportées aux sources. Elle crée également dans ce répertoire un répertoire nom_paquet-version contenant en fait les sources désarchivées. Si vous ne souhaitez pas que apt désarchive les sources après les avoir téléchargées, utilisez l'option --download-only et donc la commande apt-get source --download-only nom_paquet... mais de toute façon il vous faudra bien désarchiver les sources.

Il ne vous reste plus maintenant qu'à compiler les sources pour créer le paquet binaire. Pour ce faire vous devez tout d'abord vous placer dans le répertoire les contenant : $ cd nom_paquet-version Ceci fait soit vous passez directement à la phase de compilation et de création du paquet, soit vous apportez avant cela quelques modifications par exemple au code source, nous verrons un exemple un peu plus bas. Notez que si vous souhaitiez compiler directement le paquet sans rien modifier vous auriez pu tout simplement ajouter l'option "-b" à la commande apt-get précédente ce qui aurait donné apt-get source -b nom_paquet. Apt aurait alors non seulement téléchargé et désarchivé les sources mais encore lancé la compilation et la création du paquet. Compilez donc votre paquet : $ fakeroot dpkg-buildpackage

Un fichier binaire nom_paquet.deb a ainsi été créé dans le répertoire père du répertoire courant (celui des sources). Avant de passer à l'installation, vous devriez pouvoir tester le binaire que vous venez de compiler (./nom_binaire) Ceci fait il ne vous reste plus qu'à vous rendre dans le répertoire père et à installer (cette dernière opération se fait en root).

Récapitulons et illustrons ce qui précède à l'aide de cmatrix que nous commençons à bien connaître.

Nous cherchions dans [#ainfo S'informer sur les paquet] un économiseur d'écran console. Ceci n'est pas le mode de fonctionnement par défaut de cmatrix. Puisque nous disposons du code source, nous allons modifier ce détail, cmatrix s'arrêtera alors par défaut avec n'importe quelle touche et non uniquement avec Q. Pour cela éditez le fichier cmatrix.c puis repérez le groupe de lignes:

Modifiez alors dans les lignes précédentes le 0 de screensaver = 0, par un 1. Pour compenser cette modification repérez en peu plus bas les lignes:

Remplacez dans ces dernières lignes le 1 de screensaver = 1; par un 0. Nous avons ainsi inversé le mode par défaut et le rôle de l'option "-s". Si vous souhaitez personnaliser un peu plus vous pouvez aussi modifier par exemple la couleur par défaut. Dans les premières lignes, remplacez alors le GREEN de mcolor = COLOR_GREEN par la couleur de votre choix entre RED, BLUE, WHITE, YELLOW, CYAN, MAGENTA ou BLACK. Notez que nous pourrions aussi modifier les scripts d'installation ou de désinstallations, ou que sais-je encore... Sauvegardez, quittez, il ne vous reste plus qu'à compiler, tester et installer.

Vous trouverez également dans ce répertoire un paquet cmatrix-xfont_1.2a-2_all.deb qui a été créé par la même occasion. Installez-le aussi si vous le souhaitez. Enfin si vous voulez être certain de conserver "votre" cmatrix au cours des différentes mises à jour que vous effectuerez, n'oubliez pas de le marquer en "hold" comme nous avons vu dans [#ajour Mettre à jour sa distribution]. Par exemple : # echo "cmatrix hold" | dpkg --set-selections

Conclusion

Il y aurait encore beaucoup à écrire pour compléter cette page, la critiquer, en préciser les limites, souhaiter qu'aucune erreur ne s'y soit glissée, etc. Mais, outre mon ignorance de certains sujets, je commence à être lassé d'écrire, et vous peut-être de lire. Si vous souhaitez des informations complémentaires, je vous recommande d'aller en priorité les chercher sur le site officiel Debian et sa page Documentation. Vous y retrouverez de nombreux points évoqués ici et bien plus ; n'oubliez pas non plus les incontournables pages man.

Pour le reste laissons Richard M. Stallman, ou plutôt son double virtuel vrms, conclure brièvement pour nous (exil est le nom du PC utilisé).

Merci d'avoir lu cet article ; merci à Léa de le publier.

@ Retour à la rubrique Logiciels

Copyright

Copyright © 14/01/2005, Marc

Ce document est publié sous licence Creative Commons Attribution, Partage à l'identique, Contexte non commercial 2.0 : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/