[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ suivant ]


Guide de référence pour Debian
Chapitre 2 - Notions fondamentales sur Debian


Ce chapitre donne des notions fondamentales sur le système Debian pour des non-développeurs. Pour des informations officielles, voir :

listés dans Références, Section 15.1.

Si l'on recherche des explications basées sur des solutions et sans les détails, se référer directement à Gestion des paquets Debian, Chapitre 6 ou aux chapitres appropriés.

Ce chapitre consiste en une réorganisation de documents pris dans la « FAQ Debian », afin qu'un administrateur système Debian puisse débuter.


2.1 Les archives Debian


2.1.1 Structure de répertoires

Les logiciels paquetés pour Debian sont disponibles dans un des nombreux arbres de répertoires sur chaque site miroir Debian accessible par FTP ou HTTP.

Les répertoires suivants sont sur chaque miroir Debian sous le répertoire debian :

/dists/ :

Ce répertoire contient les « distributions », et est utilisé pour accéder aux paquets actuellement disponibles dans les versions et pré-versions de Debian. Certains vieux paquets, fichiers Contents-*.gz, et fichiers Packages.gz sont toujours là.

/pool/ :

Nouvelle place de tous les paquets des versions et pré-versions de Debian.

/tools/ :

Utilitaires DOS pour créer des disquettes de démarrage, partitionner un disque dur, compresser/décompresser des fichiers, et démarrer Linux.

/doc/ :

La documentation de base de Debian, telle que la FAQ, les instructions pour faire un rapport de bogues, etc.

/indices/ :

Le fichier Maintainers et les fichiers override.

/project/ :

Principalement des ressources pour les développeurs, comme :

project/experimental/ :

Ce répertoire contient des paquets et des outils qui sont en développement, et sont encore en état de test alpha. Les utilisateurs ne devraient pas utiliser des paquets de ce répertoire parce qu'ils peuvent être dangereux même pour des utilisateurs expérimentés.

project/orphaned/ :

Paquets qui ont été abandonnés par leur ancien responsable et ont été retirés de la distribution.


2.1.2 Distributions Debian

Normalement il y a trois distributions Debian dans le répertoire dists. Leurs noms sont la distribution « stable », la distribution « testing » et la distribution « unstable ». Quelquefois il y a aussi la distribution « frozen ». Chaque distribution est définie par un lien symbolique vers le répertoire réel, utilisant un nom de code et situé dans le répertoire dists.


2.1.3 La distribution stable

Les paquets de la distribution stable, Debian Sarge (3.1r0), sont enregistrés dans le répertoire stable (lien symbolique vers Sarge) :

En plus des emplacements ci-dessus, les paquets sont physiquement situés dans le répertoire pool (Le répertoire pool, Section 2.1.10).

L'état courant de la distribution stable est accessible sur la page web Les problèmes de 'stable'.


2.1.4 La distribution testing

Les paquets de la distribution testing, Debian Etch, sont enregistrés dans le répertoire testing (lien symbolique vers Etch) après avoir subi une certaine quantité de tests dans unstable. En plus de ces emplacements, les nouveaux paquets sont situés dans le répertoire pool (Le répertoire pool, Section 2.1.10). Les sous-répertoires main, contrib et non-free sont aussi présents dans testing, séparés par les mêmes critères que pour stable.

Les paquets doivent être synchronisés pour toutes les architectures où ils sont compilés et ne doivent pas avoir de dépendances qui les rendent ininstallables ; ils doivent aussi avoir moins de bogues critiques pour une sortie de version que ceux de unstable. De cette façon, on espère que testing est toujours prête à être candidate à une sortie. Plus de détails sur le mécanisme sont disponibles à http://www.debian.org/devel/testing.

L'état courant de la distribution testing est accessible sur les sites suivants (en Anglais) :


2.1.5 La distribution unstable

Les paquets de la distribution unstable, sid, sont enregistrés dans le répertoire unstable après avoir été téléchargés dans l'archive Debian et y restent jusqu'à ce qu'ils soient déplacés dans testing après quelque temps. Les nouveaux paquets sont situés dans le répertoire pool Le répertoire pool, Section 2.1.10. Les sous-répertoires main, contrib et non-free sont aussi présents dans unstable, et ont les mêmes fonctions que dans stable.

La distribution unstable contient une image du système en développement le plus récent. Les utilisateurs sont encouragés à utiliser et tester ces paquets, mais sont prévenus de leur état. L'avantage à utiliser unstable est que vous êtes toujours à jour avec la dernière version du projet Debian—mais si ça casse, vous en découvrez les désavantages :-)

L'état courant de la distribution unstable est accessible à la page web : Problèmes de unstable.


2.1.6 La distribution frozen

Lorsque la distribution testing est mûre, elle est gelée (NdT : frozen en Anglais), c'est-à-dire que l'on n'accepte plus de nouveau code, seulement des corrections de bogues, si nécessaire. De plus, un nouvel arbre testing est créé dans le répertoire dists, avec un nouveau nom de code. La distribution frozen subit quelques mois de test, avec par intermittence des mises à jour et des gelées complètes, ce qu'on appelle des `cycles de test'.

On garde une trace des bogues de la distribution frozen qui peuvent retarder la sortie d'un paquet ou qui peuvent retarder la sortie de la distribution complète. Lorsque le nombre de bogues descend en dessous des valeurs maximum acceptables, la distribution frozen devient stable, est sortie, et la distribution stable précédente devient obsolète (et est déplacée dans les archives).


2.1.7 Les noms de code de la distribution Debian

Les noms des répertoires physiques dans le répertoire dists, comme Sarge et Etch, sont juste des noms de code. Lorsqu'une distribution Debian est en développement, elle n'a pas de numéro de version mais un nom de code. Le but de ces noms de code est de faciliter le travail des miroirs de la distribution Debian (si un répertoire réel comme unstable changeait soudainement son nom en stable, beaucoup de données seraient à télécharger de nouveau).

Actuellement, stable est un lien symbolique vers Sarge et testing est un lien symbolique vers Etch. Cela signifie que Sarge est l'actuelle distribution stable et Etch l'actuelle distribution testing.

unstable est un lien symbolique permanent vers sid, car sid est toujours la distribution unstable.


2.1.8 Noms de code utilisés par le passé

Les noms de code qui ont déjà été utilisés sont : buzz pour la version 1.1, rex pour la version 1.2, bo pour les versions 1.3.x, hamm pour la version 2.0, slink pour la version 2.1, potato pour la version 2.2, woody pour la version 3.0 et sarge pour la version 3.1.


2.1.9 Source d'inspiration pour les noms de code

Jusqu'ici, les noms de code viennent des personnages du film Toy Story par Pixar.


2.1.10 Le répertoire pool

Historiquement, les paquets étaient gardés dans le sous-répertoire dists correspondant à la distribution qui les contenait. Il apparut que cela posait certains problèmes, tels que la grande consommation de bande passante sur les miroirs lorsque des changements majeurs étaient effectués.

Les paquets sont maintenant gardés dans un large `bassin' (NdT : pool en Anglais), structuré selon le nom du paquet source. Pour rendre cela gérable, le bassin est subdivisé par section (main, contrib et non-free) et par la première lettre du nom du paquet source. Ces répertoires contiennent plusieurs fichiers : les paquets binaires pour chaque architecture, et les paquets source à partir desquels les paquets binaires ont été générés.

Vous pouvez trouver où se trouve chaque paquet en lançant une commande comme apt-cache showsrc mypackagename et en lisant la ligne `Directory:'. Par exemple, les paquets apache sont dans pool/main/a/apache/. Il y a tellement de paquets lib* qu'ils sont traités différemment : par exemple, les paquets libpaper sont dans pool/main/libp/libpaper/.

Les répertoires dists sont toujours utilisés pour les fichiers d'index utilisés par des logiciels comme apt. De plus, les anciennes distributions n'ont pas été converties pour utiliser les bassins donc vous verrez des chemins contenant des distributions comme Potato ou Woody dans le champ d'en-tête « Filename ».

Normalement, vous n'avez pas à vous occuper de cela, puisque le nouvel apt et probalement l'ancien dpkg-ftp (voir Méthodes de mise à jour d'un système Debian, Section 2.3.1) vont gérer cela de façon transparente. Si vous souhaitez plus d'information, consultez RFC: implementation of package pools (en Anglais).


2.1.11 Notes historiques sur sid

Lorsque la sid d'aujourd'hui n'existait pas, l'organisation de l'archive Debian avait un défaut majeur : on supposait que lorsqu'une architecture était créée dans la distribution unstable courante, elle sortirait lorsque cette distribution deviendrait la nouvelle stable. Ce n'était pas le cas pour beaucoup d'architectures, ce qui entrainait que ces répertoires devaient être déplacés lors d'une sortie. Cela n'était pas pratique parce que cela consommerait beaucoup de bande passante.

Les administrateurs de l'archive contournèrent le problème pendant plusieurs années en plaçant les binaires des architectures non sorties dans un répertoire spécial nommé Sid. Lors de la sortie de ces architectures, un lien était créé entre la stable courante et Sid, et à partir de là elles étaient créées dans l'arbre unstable de façon normale. Cette disposition était quelque peu troublante pour les utilisateurs.

Avec l'arrivée des bassins de paquets (voir Le répertoire pool, Section 2.1.10) pendant le développement de la distribution Woody, les paquets binaires ont commencé à être stockés à un emplacement standard dans le bassin, quelle que soit la distribution, de façon à ce que sortir une distribution ne cause plus de grande consommation de bande passante sur les miroirs (il y a, cependant, beaucoup de consommation de bande passante, mais graduellement, pendant le développement).


2.1.12 Paquets téléchargés dans incoming

Les paquets téléchargés sont d'abord placés dans http://incoming.debian.org/ avant que l'on ne vérifie s'ils viennent bien d'un développeur Debian (et sont placés dans le sous-répertoire DELAYED dans le cas d'un téléchargement par un non responsable (Non-Maintainer Upload, NMU)). Une fois par jour, ils sont déplacés de incoming vers unstable.

En cas d'urgence, vous pouvez vouloir installer des paquets de incoming avant qu'ils n'atteignent unstable.


2.1.13 Récupérer un paquet ancien

Alors que les distributions Debian récentes sont gardées dans le répertoire debian de chaque miroir Debian, les archives des anciennes distribution comme Slink sont gardées sur http://archive.debian.org/ ou dans le répertoire debian-archive de chaque miroir Debian.

Les anciens paquets de testing et unstable sont situés à http://snapshot.debian.net/.


2.1.14 Sections architectures

Dans chacun des arbres de répertoires majeurs (dists/stable/main, dists/stable/non-free, dists/unstable/main/, etc.), les paquets binaires résident dans des sous-répertoires dont le nom indique l'architecture pour laquelle ils ont été compilés.

Veuillez noter que les paquets binaires pour testing et unstable ne résident plus dans ces répertoires, mais dans le répertoire de haut niveau pool. Les fichiers d'index (Packages et Packages.gz) ont été gardés, cependant, pour une compatibilité arrière.

Pour les architectures binaires supportées, consultez les Notes de version de chaque distribution. Elles sont disponibles sur les sites des notes de version pour stable et testing.


2.1.15 Le code source

Le code source est inclut pour tout le système Debian. De plus, les termes de la licence de la plupart des logiciels du système requièrent que le code source soit distribué avec le programme, ou qu'une offre permettant d'obtenir le code source accompagne le programme.

Normalement, le code source est distribué dans les répertoires source, qui sont parallèles aux répertoires contenant les binaires spécifiques à une architecture, ou plus récemment dans le répertoire pool (voir Le répertoire pool, Section 2.1.10). Pour récupérer le code source sans avoir à être familier avec la structure de l'archive Debian, essayez une commande comme apt-get source mypackagename.

Certains paquets, notamment pine, sont seulement disponibles sous forme de paquet source, à cause de limitations de leur licence. (Récemment, le paquet pine-tracker a été fourni pour faciliter l'installation de Pine.) Les procédures décrites dans Porter un paquet vers le système stable, Section 6.4.10 et Paquetage, Section 13.9 permettent de construire un paquet manuellement.

Le code source peut être ou ne pas être disponible pour les paquets dans les répertoires contrib et non-free, qui ne font pas formellement partie du système Debian.


2.2 Système de gestion des paquets Debian


2.2.1 Vue générale des paquets Debian

Les paquets contiennent généralement tous les fichiers nécessaires pour implémenter un ensemble de commandes ou caractéristiques. Il existe deux types de paquets Debian :

L'installation de logiciels par le système de paquets utilise des « dépendances » qui sont soigneusement conçues par les responsables du paquet. Ces dépendances sont documentées dans le fichier control associé à chaque paquet. Par exemple, le paquet contenant le compilateur GNU C (gcc) « dépend » du paquet binutils qui inclut l'éditeur de liens et l'assembleur. Si un utilisateur tente d'installer gcc sans avoir d'abord installé binutils, le système de gestion de paquets (dpkg) renverra un message d'erreur disant qu'il a besoin de binutils, et cessera l'installation de gcc. (Cependant, un utilisateur insistant pourra passer outre ; voir dpkg(8).) Pour plus de détails, voir Dépendances des paquets, Section 2.2.8 ci-dessous.

Les outils de paquetage de Debian peuvent être utilisés pour :


2.2.2 Format des paquets Debian

Un « paquet » Debian, ou un fichier d'archive Debian, contient les fichiers exécutables, les bibliothèques, et la documentation associés à un programme particulier ou un ensemble de programmes liés. Normalement, une archive Debian possède un nom de fichier se terminant par .deb.

Les données internes de ce format de paquets binaires Debian sont décrites dans la page de manuel deb(5). Parce que ce format interne est sujet à des changements (entre les sorties majeures de Debian), utilisez toujours dpkg-deb(1) pour manipuler des fichiers .deb.

Au moins jusqu'à la distribution Woody, tous les fichiers d'archive Debian étaient manipulés par les commandes Unix standard ar et tar, même lorsque les commandes dpkg n'étaient pas disponibles.


2.2.3 Conventions de nommage pour les fichiers de paquets Debian

Les noms de fichiers des paquets Debian se conforment à la convention suivante :

     foo_VersionNumber-DebianRevisionNumber.deb

foo représente le nom du paquet. Pour vérification, on peut déterminer le nom du paquet associé à un fichier d'archive Debian particulier (fichier .deb) de l'une des façons suivantes :

La composante VVV est le numéro de version spécifié par le développeur original. Il n'y a aucune norme spécifiant la numérotation des versions, donc elle peut avoir des formats aussi différents que « 19990513 » et « 1.3.8pre1 ».

La composante RRR est le numéro de révision Debian spécifié par le développeur Debian (ou un utilisateur s'il choisit de construire le paquet lui-même). Ce numéro correspond au niveau de révision du paquet Debian ; ainsi, un nouveau niveau de révision correspond habituellement à un changement dans le Makefile Debian (debian/rules), le fichier de contrôle Debian (debian/control), les scripts d'installation ou de suppression (debian/p*), ou les fichiers de configuration utilisés avec le paquet.


2.2.4 Préservation de la configuration locale

La préservation des fichiers configurables par l'utilisateur est activée par le mécanisme « conffiles » de Debian. Les fichiers de configuration de l'utilisateur (habituellement placés dans /etc) sont spécifiés dans le fichier conffiles du système de paquets Debian. Le système de gestion des paquets garantie que ces fichiers ne seront pas recouverts lors de la mise à jour d'un paquet.

Lorsqu'il est possible de configurer le système sans modifier les fichiers qui appartiennent aux différents paquets Debian, il est conseillé de ne pas les modifier même si ce sont des « conffiles ». Cela permet des opérations de mise à jour plus rapides et en douceur.

Pour déterminer exactement quels sont les fichiers préservés lors d'une mise à jour, lancez la commande :

     dpkg --status package

et regardez la ligne « Conffiles: ».

Les détails du contenu d'un fichier Debian conffiles sont fournis dans la Charte Debian, section 11.7 (voir Références, Section 15.1).


2.2.5 Scripts de maintenance Debian

Les scripts de maintenance Debian sont des scripts exécutables qui sont automatiquement exécutés avant ou après l'installation d'un paquet. Avec un fichier nommé control, tous ces fichiers font partie de la section « control » d'un fichier d'archive Debian.

Les fichiers individuels sont :

preinst

Ce script est exécuté avant que son paquet soit dépaqueté de son archive Debian (.deb). Beaucoup de scripts « preinst » arrêtent les services fournis par les paquets mis à jour jusqu'à ce que leur installation ou mise à jour soit complète (après l'exécution avec succès du script « postinst »).

postinst

Ce script complète la configuration requise par un paquet après son dépaquetage à partir de son archive Debian (.deb). Souvent, les scripts « postinst » demandent à l'utilisateur d'entrer des informations et/ou l'avertissent que s'il accepte les valeurs par défaut, il devrait se rappeler de revenir en arrière et reconfigurer le paquet lorsque la situation le requiert. Beaucoup de scripts « postinst » exécutent ensuite les commandes nécessaires au redémarrage d'un service une fois que le nouveau paquet a été installé ou mis à jour.

prerm

Ce script arrête les daemons qui sont associés à un paquet. Il est exécuté avant la suppression de fichiers associés au paquet.

postrm

Ce script modifie les liens ou les autres fichiers associés à un paquet, et/ou supprime les fichiers créés. (Voir aussi Paquets virtuels, Section 2.2.7.)

Actuellement, tous les fichiers de contrôle peuvent être trouvés dans le répertoire /var/lib/dpkg/info. Les fichiers associés au paquet foo commencent avec le nom « foo » et ont des extensions « preinst », « postinst », etc., tel qu'approprié. Le fichier foo.list dans ce répertoire liste tous les fichiers qui ont été installés avec le paquet foo. (Notez que l'emplacement de ces fichiers est interne à dpkg, et peut changer.)


2.2.6 Priorité des paquets

Chaque paquet Debian se voit assigner une priorité par les responsables de la distribution, comme aide au système de gestion des paquets. Les priorités sont :


2.2.7 Paquets virtuels

Un paquet virtuel est un nom générique qui s'applique à n'importe quel paquet d'un groupe de paquets, qui tous fournissent une fonctionalité de base similaire. Par exemple, les logiciels tin et trn sont des lecteurs de groupes de discussion, et doivent donc satisfaire la dépendance d'un programme ayant besoin d'une tel lecteur sur le système pour fonctionner ou être utile. On dit qu'ils fournissent tous les deux le « paquet virtuel » appelé news-reader.

De façon similaire, exim et sendmail fournissent tous les deux la fonctionalité d'un agent de transport de courrier électronique. On dit donc qu'ils fournissent le paquet virtuel « mail transport agent ». Si l'un des deux est installé, un programme dépendant de l'installation d'un mail-transport-agent sera satisfait par la présence de ce paquet virtuel.

Debian fournit un mécanisme pour que, si plus d'un paquet qui fournit le même paquet virtuel est installé sur un système, l'administrateur puisse configurer l'un des deux comme paquet préféré. La commande utilisée est update-alternatives, et est décrite dans Commandes de rechange, Section 6.5.3.


2.2.8 Dépendances des paquets

Le système de paquets Debian possède une série de « dépendances » de paquets qui sont conçues pour indiquer (avec un simple drapeau) le niveau auquel Programme A peut fonctionner indépendamment de la présence de Programme B sur le système :

Plus de détails sur l'utilisation de ces termes sont fournis dans le Manuel de Paquetage et dans la Charte Debian.

Notez que dselect permet un contrôle plus précis sur les paquets marqués recommends et suggests que apt-get, qui récupère simplement tous les paquets spécifiés par depends et laisse les paquets spécifiés par recommends et suggests. Les deux programmes utilisent APT comme dorsale dans leurs versions modernes.


2.2.9 Signification de « pre-depends »

« Pre-depends » est une dépendance spéciale. Dans le cas d'un paquet ordinaire, dpkg dépaquètera le fichier archive (càd. le fichier .deb) indépendamment de la présence ou non des fichiers dont il dépend sur le système. En simplifiant, dépaqueter signifie que dpkg extrait les fichiers de l'archive qui sont censés être installés sur votre système et les met à leur place. Si ces paquets dépendent de la présence d'autres paquets sur votre système, dpkg refusera de compléter l'installation (en exécutant son action « configure ») tant que les autres paquets ne seront pas installés.

Cependant, pour certains paquets, dpkg refusera même de les dépaqueter tant que certaines dépendances ne seront pas satisfaites. On dit que ces paquets « pré-dépendent » de la présence d'autres paquets. Le projet Debian fournissait ce mécanisme pour supporter la mise à jour sûre des systèmes du format a.out au format ELF, pendant laquelle l'ordre dans lequel les paquets étaient dépaquetés était critique. Il y a d'autres situations de mise à jour pour lesquelles cette méthode est utile, par exemple pour les paquets avec la priorité « required » et leur dépendance à la libc.

Une fois de plus, de plus amples informations peuvent être trouvées dans le Manuel de Paquetage.


2.2.10 Etat d'un paquet

L'état d'un paquet peut être « unknown » (inconnu), « install » (installe), « remove » (supprime), « purge » (purge), ou « hold » (garde). Ces drapeaux « want » (volonté) indiquent ce que l'utilisateur souhaite faire avec un paquet (comme indiqué soit par les actions de l'utilisateur dans la section « Select » de dselect, soit par l'invocation directe de dpkg).

Leur signification est :


2.2.11 Garder des paquets lors d'une mise à jour

Il y a deux mécanismes pour garder des paquets lors de la mise à jour, à l'aide de dpkg, ou, dans Woody, à l'aide d'APT.

Avec dpkg, exportez d'abord la liste des sélections de paquets :

     dpkg --get-selections \* > selections.txt

Ensuite, éditez le fichier résultant selections.txt, en changeant la ligne contenant le paquet que vous souhaitez garder, e.g. libc6, de :

     libc6                       install

en :

     libc6                       hold

Sauvegardez le fichier, et rechargez-le dans la base de données de dpkg avec la commande :

     dpkg --set-selections < selections.txt

Ou, si vous connaissez le nom du paquet à garder, exécutez simplement :

     echo libc6 hold | dpkg --set-selections

Ce procédé garde les paquets pendant la procédure d'installation de chaque paquet.

Le même résultat peut être obtenu avec dselect. Entrez simplement dans l'écran [S]elect, trouvez le paquet que vous souhaitez garder en l'état et appuyez sur la touche `=' (ou `H'). Les changements prendront effet immédiatement après que vous êtes sortis de l'écran [S]elect.

Le système APT dans la distribution Woody possède un nouveau mécanisme pour garder les paquets pendant la procédure de récupération des archives en utilisant Pin-Priority. Voir la page de manuel apt_preferences(5), ainsi que http://www.debian.org/doc/manuals/apt-howto/ ou le paquet apt-howto.


2.2.12 Paquets sources

Les paquets sources sont distribués dans un répertoire appelé source, et vous pouvez soit les télécharger manuellement, soit utiliser

     apt-get source foo

pour les récupérer (voir la page de manuel apt-get(8) pour configurer APT pour faire cela).


2.2.13 Construire des paquets binaires à partir d'un paquet source

Pour un paquet foo, vous aurez besoin de tous les fichiers foo_*.dsc, foo_*.tar.gz et foo_*.diff.gz pour compiler les sources (note : il n'y a pas de fichier .diff.gz pour les paquets Debian natifs).

Une fois que vous les avez, si vous avez le paquet dpkg-dev installé, la commande

     $ dpkg-source -x foo_version-revision.dsc

va extraire le paquet dans un répertoire appelé foo-version.

Lancez la commande suivante pour compiler le paquet binaire :

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

Puis,

     $ su -c "dpkg -i ../foo_version-revision_arch.deb"

pour installer le paquet nouvellement construit. Voir Porter un paquet vers le système stable, Section 6.4.10.


2.2.14 Créer de nouveaux paquets Debian

Pour une description plus détaillée de la création de nouveaux paquets, lisez le Guide des nouveaux responsables Debian, disponible dans le paquet maint-guide, ou à l'adresse http://www.debian.org/doc/manuals/maint-guide/.


2.3 Mettre à jour un système Debian

L'un des buts de Debian est de fournir un chemin de mise à jour consistant et un processus de mise à jour sûr, et nous faisons de notre mieux pour que la mise à jour lors de la sortie d'une nouvelle version depuis une précédente soit la plus douce possible. Les paquets vont alerter l'utilisateur lorsqu'il y a des avertissements importants pendant le processus de mise à jour, et vont souvent fournir une solution à un problème possible.

Vous devriez aussi lire les Notes de version, le document qui décrit les détails des mises à jour spécifiques, livré sur tous les CDs Debian, et disponible sur le WWW aux adresses http://www.debian.org/releases/stable/releasenotes et http://www.debian.org/releases/testing/releasenotes.

Un guide pratique pour les mises à jour est fourni dans la Gestion des paquets Debian, Chapitre 6. Cette section décrit les détails fondamentaux.


2.3.1 Méthodes de mise à jour d'un système Debian

On pourrait simplement exécuter une session FTP anonyme ou un appel à wget vers une archive Debian, parcourir les répertoires jusqu'à ce qu'on trouve le fichier désiré, le récupérer, et enfin l'installer en utilisant dpkg. (Notez que dpkg installera les fichiers de la mise à jour à leur place, même sur un système en marche.) Parfois, un paquet révisé aura besoin de l'installation d'une version révisée d'un autre paquet, auquel cas l'installation échouera si l'autre paquet n'est pas installé.

Beaucoup de gens trouvent cette approche trop gourmande en temps, car Debian évolue très rapidement — typiquement, une douzaine ou plus de nouveaux paquets sont téléchargés chaque semaine. Ce nombre est encore plus grand avant la sortie d'une version majeure. Pour gérer cette avalanche, beaucoup de gens préfèrent utiliser une méthode automatique. Plusieurs outils de gestion des paquets sont disponibles dans ce but.


2.3.2 Vue générale des outils de gestion de paquets

Le système de gestion de paquets Debian a deux objectifs : la manipulation des fichiers de paquets eux-mêmes et la récupération de fichiers de paquets depuis une archive Debian. dpkg réalise la première fonction, APT et dselect la seconde.


2.3.3 dpkg

C'est le programme principal pour manipuler les fichiers de paquets ; consultez dpkg(8) pour une description complète.

dpkg vient avec plusieurs programmes primitifs supplémentaires.

dpkg-ftp et dpkg-mountable ont été rendus obsolètes par l'introduction du système APT.


2.3.4 APT

APT (Advanced Packaging Tool, outil avancé de paquetage) est une interface avancée pour le système de gestion des paquets Debian, qui consiste en plusieurs programmes dont les noms commencent par « apt- ». apt-get, apt-cache et apt-cdrom sont les outils en ligne de commande pour gérer les paquets. Ils fonctionnent aussi en tant que dorsale pour d'autres outils, comme dselect et aptitude.

Pour plus d'information, installez le paquet apt et lisez apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (woody), et /usr/share/doc/apt/guide.html/index.html.

Une autre source d'information est le APT HOWTO. Il peut être installé par le paquet apt-howto à l'emplacement /usr/share/doc/Debian/apt-howto/.

apt-get upgrade et apt-get dist-upgrade récupèrent seulement les paquets marqués « Depends: » et passe outre tous les paquets marqués « Recommends: » et « Suggests: ». Pour éviter cela, utilisez dselect.


2.3.5 dselect

Ce programme est une interface utilisateur avec un menu pour le système de gestion de paquets Debian. Il est particulièrement utile pour les premières installations et les grosses mises à jour.

Pour plus d'information, installez le paquet install-doc et lisez /usr/share/doc/install-doc/dselect-beginner.en.html ou Documentation dselect pour débutants.


2.3.6 Mise à jour d'un système en marche

Le noyau (système de fichiers) des systèmes Debian supporte le recouvrement de fichiers même lorsqu'ils sont en utilisation.

Nous fournissons aussi un programme appelé start-stop-daemon qui est utilisé pour démarrer les daemon lors du démarrage du système ou pour les arrêter lorsque le niveau de fonctionnement du noyau est changé (par exemple de multi-utilisateur vers mono-utilisateur ou vers arrêt). Le même programme est utilisé par les scripts d'installation lorsqu'un nouveau paquet contenant un daemon est installé, pour arrêter les daemons en exécution, et les redémarrer lorsque cela est nécessaire.

Notez que le système Debian ne requiert pas l'utilisation du mode mono-utilisateur pour mettre à jour un système en marche.


2.3.7 Fichiers d'archive .deb téléchargés et sauvegardés

Si vous avez téléchargé manuellement des fichiers de paquets sur votre disque (ce qui n'est pas forcément nécessaire, voir ci-dessus pour la description de dpkg-ftp ou APT), vous pouvez supprimer les fichiers .deb de votre système lorsque les paquets ont été installés.

Si APT est utilisé, ces fichiers sont mis en cache dans le répertoire /var/cache/apt/archives/. Vous pouvez les effacer après l'installation (apt-get clean) ou les copier sur une autre machine dans le répertoire /var/cache/apt/archives/ pour économiser du temps de téléchargement pendant les installations suivantes.


2.3.8 Garder une trace des mises à jour

dpkg garde un enregistrement des paquets qui ont été dépaquetés, configurés, supprimés, et/ou purgés, mais il ne garde pas (pour le moment) de journal de l'activité du terminal qui a eu lieu lorsqu'un paquet a été manipulé.

Le moyen le plus simple de contourner cela est de lancer vos sessions dpkg, dselect, apt-get, etc. avec le programme script(1).


2.4 Le processus de démarrage de Debian


2.4.1 Le programme init

Comme tous les Unices, Debian démarre en exécutant le programme init. Le fichier de configuration de init (qui est /etc/inittab) spécifie que le premier script à exécuter doit être /etc/init.d/rcS. Ce script lance tous les scripts de /etc/rcS.d/ en incluant le source ou en forkant un sous-processus, selon leur extension, pour exécuter des initialisations, comme la vérification et le montage des systèmes de fichiers, le chargement des modules, le démarrage des services réseau, le réglage de l'horloge, et l'exécution d'autres initialisations. Ensuite, pour compatibilité, il lance aussi les fichiers (sauf ceux ayant un « . » dans leur nom) de /etc/rc.boot/. Les scripts de ce dernier répertoire sont habituellement réservés à l'administrateur système, et leur utilisation dans des paquets est obsolète. Voir Initialisation du système, Section 9.1 pour plus d'information.


2.4.2 Niveaux de fonctionnement

Après le processus de démarrage, init exécute les scripts de démarrage situés dans le répertoire correspondant au niveau de fonctionnement par défaut (ce niveau de fonctionnement est donné par l'entrée id dans /etc/inittab). Comme la plupart des Unices compatibles System V, Linux a 7 niveaux de fonctionnement :

Les systèmes Debian sont livrés avec id=2, ce qui indique que le niveau de fonctionnement par défaut sera 2 lorsqu'on entrera dans l'état multi-utilisateur, et les scripts de /etc/rc2.d/ seront exécutés.

En fait, les scripts des répertoires /etc/rcN.d/ sont des liens symboliques vers les scripts de /etc/init.d. Cependant, les noms des fichiers dans chacun des répertoires /etc/rcN.d/ sont sélectionnés pour indiquer la façon dont les scripts de /etc/init.d/ seront exécutés. Spécifiquement, avant d'entrer dans un niveau de fonctionnement, tous les scripts commençant par `K' sont lancés ; ils permettent d'arrêter des services. Ensuite, tous les scripts commençant par `S' sont lancés ; ces scripts permettent de démarrer des services. Le nombre à deux chiffres suivant le `K' ou le `S' indique l'ordre dans lequel le script est lancé. Les scripts possédant les nombres les plus petits sont exécutés en premier.

Cette approche fonctionne parce que les scripts dans /etc/init.d/ prennent tous un argument qui peut être "start", "stop", "reload", "restart" ou "force-reload" et exécuteront la tâche indiquée par cet argument. Ces scripts peuvent être utilisés même après que le système a été démarré, pour contrôler divers processus.

Par exemple, avec l'argument « reload », la commande

     # /etc/init.d/exim4 reload

envoie au daemon exim4 un signal pour qu'il relise son fichier de configuration.


2.4.3 Personnaliser les niveaux de fonctionnement

Personnaliser les niveaux de fonctionnement est une tâche d'administration avancée. Les conseils suivants fonctionnent pour la plupart des services.

Pour activer le service service dans le niveau de fonctionnement R, créez le lien symbolique /etc/rcR.d/Sxyservice avec comme cible ../init.d/service. Le numéro xy doit être le numéro assigné au service lors de l'installation du paquet.

Pour désactiver le service, renommez le lien symbolique en le faisant commencer par K à la place de S et en lui donnant le numéro 100 moins xy.

Il est plus facile d'utiliser un éditeur de niveaux de fonctionnement, comme sysv-rc-conf ou ksysv pour effectuer ces modifications.

Il est possible de supprimer le lien symbolique S d'un service dans le répertoire d'un niveau de fonctionnement au lieu de le renommer. Cela ne désactive pas le service, mais le laisse dans un état « flottant » du point de vue du système d'initialisation sysv-rc : lors d'un changement de niveau de fonctionnement, le service ne sera ni démarré ni arrêté mais sera laissé tel quel, qu'il soit en fonctionnement ou pas. Notez cependant qu'un service laissé dans un tel état sera démarré si son paquet est mis à jour, qu'il soit en fonctionnement ou pas lors de la mise à jour. C'est un défaut du système Debian actuel. Notez aussi que vous devriez laisser le lien symbolique K d'un service dans les niveaux de fonctionnement 0 et 6. Si vous supprimez tous les liens symboliques d'un service, le paquet les restaurera lors d'une mise à jour.

Il n'est pas conseillé de faire des changements sur les liens symboliques de /etc/rcS.d/.


2.5 Support de la diversité

Debian offre plusieurs facilités pour exaucer les voeux des administrateurs du système sans casser ce dernier.

Les fichiers situés sous /usr/local/ appartiennent à l'administrateur du système et Debian n'y touchera pas. La plupart (ou tous) les fichiers sous /etc sont des conffiles (fichiers de configuration) et Debian n'écrira pas dessus lors d'une mise à jour sauf si l'administrateur le spécifie explicitement.


2.6 Internationalisation

Le système Debian est internationalisé et fournit le support pour l'affichage et l'entrée des caractères de beaucoup de langues, à la fois avec la console ou sous X. Beaucoup de documents, de pages de manuel, et de messages système ont été traduits dans un nombre toujours plus élevé de langues. Lors de l'installation, Debian demande à l'utilisateur de choisir une langue pour l'installation (et parfois une variante locale de cette langue).

Si votre système installé ne supporte pas toutes les possibilités de la langue dont vous avez besoin, si vous avez besoin de changer de langue ou d'installer un clavier différent pour supporter votre langue, voyez Localisation (l10n), Section 9.7.


2.7 Debian et le noyau

Voir Le noyau Linux et Debian, Chapitre 7.


2.7.1 Compiler un noyau avec des sources non Debian

Il faut comprendre la politique Debian sur les en-têtes.

Les bibliothèques C de Debian sont compilées avec les en-têtes du noyau stable le plus récent.

Par exemple, la version Debian-1.2 utilisait la version 5.4.13 des en-têtes. Cette pratique contraste avec les paquets source du noyau Linux distribués dans toutes les archives FTP Linux, qui utilisent des versions encore plus récentes des en-têtes. Les en-têtes du noyau distribuées avec le source du noyau sont situées dans /usr/include/linux/include/.

Si vous avez besoin de compiler un programme avec des en-têtes du noyau plus récentes que celles fournies par libc6-dev, alors vous devez ajouter -I/usr/src/linux/include/ à la ligne de commande lorsque vous compilez. Cela est arrivé, par exemple, avec l'empaquetage du daemon automounter (amd). Lorsque de nouveaux noyaux ont changé les commandes internes ayant trait à NFS, amd a dû en prendre connaissance. Cela a requis d'inclure les dernières en-têtes du noyau.


2.7.2 Outils pour compiler un noyau personnalisé

Les utilisateurs qui souhaitent (ou doivent) compiler un noyau personnalisé sont encouragés à télécharger le paquet kernel-package. Ce paquet contient le script pour construire le paquet du noyau, et fournit la possibilité de créer un paquet kernel-image Debian en exécutant la commande

     # make-kpkg kernel_image

dans le répertoire le plus haut des sources du noyau. De l'aide est disponible en exécutant la commande

     # make-kpkg --help

et dans la page de manuel make-kpkg(1) et Le noyau Linux et Debian, Chapitre 7.

Les utilisateurs doivent télécharger séparément le code source du dernier noyau (ou le noyau de leur choix) depuis leur archive FTP Linux favorite, à moins qu'un paquet kernel-source-version soit disponible (où version indique la version du noyau). Le script de démarrage initrd de Debian nécessite un patch spécial pour le noyau appelé initrd ; voir http://bugs.debian.org/149236.

Des instructions détaillées pour utiliser le paquet kernel-package sont fournies dans le fichier /usr/doc/kernel-package/README.


2.7.3 Dispositions spéciales pour manipuler les modules

Le paquet Debian modconf fournit un script shell (/usr/sbin/modconf) qui peut être utilisé pour personnaliser la configuration des modules. Ce script présente une interface à base de menus, demandant à l'utilisateur les pilotes de périphériques présents sous forme de modules chargeables qu'ils souhaite utiliser sur son système. Les réponses sont utilisées pour personnaliser le fichier de configuration /etc/modules.conf (qui liste les alias, et autres arguments qui doivent être utilisés par les différents modules) grâce aux fichiers /etc/modutils/, et /etc/modules (qui liste les modules qui doivent être chargés lors du démarrage).

Comme les (nouveaux) fichiers Configure.help qui sont maintenant disponibles pour supporter la compilation de noyaux personnalisés, le paquet modconf est livré avec une série de fichiers d'aide (dans /usr/share/modconf/) qui fournissent des informations détaillées sur les arguments possibles pour chacun des modules. Voir Le noyau 2.4 modulaire, Section 7.2 pour des exemples.


2.7.4 Désinstaller le paquet d'un vieux noyau

Le script kernel-image-NNN.prerm vérifie que le noyau que vous exécutez actuellement n'est pas le noyau à désinstaller. Ainsi, vous pouvez supprimer de façon sûre les noyaux dont vous ne voulez plus avec cette commande :

     # dpkg --purge --force-remove-essential kernel-image-NNN

(Remplacez NNN par la version et la révision de votre noyau, bien sûr.)


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ suivant ]


Guide de référence pour Debian

CVS, jeu 18 jan 2007 11:52:23 UTC

Osamu Aoki osamu#at#debian.org
Traduction en Français : Guillaume Erbs gerbs#at#free.fr
Auteurs, Section A.1