[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ suivant ]
Ce chapitre donne des notions fondamentales sur le système Debian pour des non-développeurs. Pour des informations officielles, voir :
Charte Debian
Référence du développeur Debian
Guide des nouveaux responsables Debian
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.
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.
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.
Les paquets de la distribution stable, Debian Sarge (3.1r0), sont enregistrés dans le répertoire stable (lien symbolique vers Sarge) :
stable/main/ : Ce répertoire contient les paquets constituant
la version la plus récente du système Debian.
Ces paquets sont aussi conformes aux Principes du logiciel
libre selon Debian (aussi disponible dans le fichier
/usr/share/doc/debian/social-contract.txt installé par le paquet
debian-doc), et sont tous utilisables et redistribuables
librement.
stable/non-free/ : Ce répertoire contient des paquets dont la
distribution est restreinte et nécessite que les distributeurs prennent
soigneusement en compte les exigences spécifiées par la licence.
Par exemple, certains paquets ont une licence qui interdit la distribution commerciale. D'autres peuvent être redistribués mais sont en fait des partagiciels et non des logiciels libres. Les licences de chacun de ces paquets doivent être étudiées, et dans certains cas négociées, avant que les paquets soient inclus dans une redistribution (par exemple, sur un CD-ROM).
stable/contrib/ : Ce répertoire contient des paquets qui sont
conformes aux principes du logiciel libre selon Debian et distribuables
librement, mais dépendent d'un paquet qui n'est pas
distribuable librement et n'est ainsi disponible que dans la section non-free.
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'.
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) :
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.
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).
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.
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.
Jusqu'ici, les noms de code viennent des personnages du film Toy Story par Pixar.
buzz (Buzz Lightyear) est le cosmonaute,
rex est le tyranosaure,
bo (Bo Peep) est la fille qui s'occupe du mouton,
hamm est la tirelire en forme de cochon,
slink (Slinky Dog) est le chien,
potato est, bien sûr, Mr. Potato
woody est le cowboy,
sarge est un chef des Hommes de l'Armée de Plastique Vert,
etch (Etch-a-Sketch) est le tableau,
sid est le garçon d'à côté qui détruit les jouets.
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).
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).
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.
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/.
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.
binary-all/, pour les paquets indépendants de l'architecture.
Cela inclut, par exemple, des scripts Perl, ou de la documentation pure.
binary-platform/, pour les paquets qui s'exécutent sur
une plateforme particulière.
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.
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.
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 :
Les paquets binaires, qui contiennent des exécutables, des fichiers de configuration, des pages de man/info, la licence, et d'autres documentations. Ces paquets sont distribués dans un format d'archive spécifique à Debian (voir Format des paquets Debian, Section 2.2.2) ; on les reconnaît habituellement à leur extension .deb. Les paquets binaires peuvent être dépaquetés en utilisant l'utilitaire Debian dpkg ; les détails sont fournis dans sa page de manuel.
Les paquets sources, qui consistent en un fichier .dsc décrivant le paquet source (y compris le nom des fichiers suivants), un fichier .orig.tar.gz qui contient le source original non-modifié compressé par tar et gzip, et habituellement un fichier .diff.gz qui contient les modifications du source original spécifiques à Debian. L'utilitaire dpkg-source empaquète et dépaquète les archives source Debian ; les détails sont fournis dans sa page de manuel.
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 :
manipuler et gérer des paquets ou des parties de paquets,
aider l'utilisateur à découper des paquets qui doivent être transmis à travers un média de taille limitée comme une disquette,
aider les développeurs à construire des archives de paquets, et
aider les utilisateurs à installer des paquets qui se trouvent sur un site d'archive 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.
Les noms de fichiers des paquets Debian se conforment à la convention suivante :
foo_VersionNumber-DebianRevisionNumber.deb
où 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 :
inspecter le fichier Packages dans le répertoire où il était
stocké sur un site d'archive Debian. Ce fichier contient une description de
chaque paquet ; le premier champ de chaque paragraphe est le nom de paquet
formel.
utiliser la commande dpkg --info foo_VVV-RRR.deb (où VVV et RRR sont les numéros de version et de révision du paquet en question, respectivement). Cela affiche, entre autres, le nom du paquet correspondant au fichier d'archive dépaqueté.
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.
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).
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 :
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 »).
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.
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.
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.)
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 :
Les paquets Required (requis) sont nécessaires au bon fonctionnement du système.
Ceci inclut tous les outils nécessaires pour réparer les défauts du système. Vous ne devez pas supprimer ces paquets, sinon le système peut devenir complètement planté et vous ne pourrez probablement plus utiliser dpkg pour remettre les choses en place. Un système avec seulement les paquets requis ne sera probablement pas utilisable, mais il sera suffisament fonctionnel pour que l'administrateur le démarre et installe plus de logiciels.
Les paquets Important devraient se trouver sur n'importe quel système de type Unix.
D'autres paquets sans lesquel le système ne fonctionnera pas bien ou ne sera pas utilisable se trouveront ici. Cela n'inclut PAS Emacs ou X11 ou TeX ou n'importe quelle autre grosse application. Ces paquets constituent seulement une infrastructure de base.
Les paquets Standard sont standard sur n'importe quel système Linux, et comprennent un système en mode texte raisonnablement petit mais pas trop limité.
C'est ce qui sera installé par défaut si les utilisateurs ne sélectionnent rien d'autre. Cela n'inclut pas beaucoup de grosses applications, mais cela inclut Emacs (qui est plus une partie d'infrastructure qu'une application) et un sous-ensemble raisonnable de TeX et LaTeX (si cela est possible sans X).
Les paquets Optional (optionnel) incluent tous ceux que vous pourriez raisonnablement vouloir installer même s'ils ne vous sont pas familiers, et si vous n'avez pas de besoins spécifiques.
Cela inclut X11, une distribution complète de TeX, et beaucoup d'applications.
Les paquets Extra (en plus) sont des paquets qui soit entrent en conflit avec des paquets ayant une priorité plus haute, soit ne seront utiles que si vous les connaissez, soit ont besoin de prérequis spécifiques qui les rendent peu convenables pour « Optional ».
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.
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 :
Paquet A depends (dépend) de Paquet B si B doit absolument être installé pour exécuter A. Dans certains cas, A dépend non seulement de B, mais d'une certaine version de B. Dans ce cas, la dépendance sur la version est habituellement une limite basse, dans le sens où A dépend de n'importe quelle version de B plus récente que la version spécifiée.
Paquet A recommends (recommande) Paquet B si le responsable du paquet juge que la plupart des utilisateurs ne voudront pas de A sans avoir la fonctionnalité fournie par B.
Paquet A suggests (suggère) Paquet B si B contient des fichiers qui sont liés à (et habituellement améliorent) la fonctionnalité de A.
Paquet A conflicts (est en conflit) avec Paquet B lorsque A ne fonctionnera pas si B est installé sur le système. Souvent, les conflits sont dans des cas où A contient des fichiers qui fournissent une amélioration par rapport à ceux de B. « conflicts » est souvent associé avec « replaces ».
Paquet A replaces (remplace) Paquet B lorsque les fichiers installés par B sont supprimés et (dans certains cas) recouverts par des fichiers de A.
Paquet A provides (fournit) Paquet B lorsque tous les fichiers et fonctionnalités de B sont incorporés dans A. Ce mécanisme fournit un moyen aux utilisateurs ayant des limitations en espace disque de ne sélectionner que la partie de A dont ils ont réellement besoin.
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.
« 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.
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 :
unknown - (inconnu) l'utilisateur n'a jamais indiqué s'il souhaite le paquet.
install - (installe) l'utilisateur veut que le paquet soit installé ou mis à jour.
remove - (supprime) l'utilisateur veut que le paquet soit supprimé, mais ne veut pas supprimer les fichiers de configuration existants.
purge - l'utilisateur veut que le paquet soit supprimé complètement, y compris ses fichiers de configuration.
hold - (garde) l'utilisateur veut que le paquet ne soit pas traité, càd. qu'il veut garder la version actuelle dans l'état actuel.
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.
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).
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.
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/.
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.
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.
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.
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-deb : Manipule les fichiers .deb.
dpkg-deb(1)
dpkg-ftp : Une ancienne commande de récupération de fichiers de paquets.
dpkg-ftp(1)
dpkg-mountable : Une ancienne commande de récupération de fichiers de
paquets. dpkg-mountable(1)
dpkg-split : Scinde un gros paquet en fichiers plus petits.
dpkg-split(1)
dpkg-ftp et dpkg-mountable ont été rendus obsolètes
par l'introduction du système 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.
dselectCe 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.
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.
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.
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).
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.
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 :
0 (arrête le système),
1 (mode mono-utilisateur),
2 à 5 (différents modes multi-utilisateur), et
6 (redémarre le système).
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.
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/.
Debian offre plusieurs facilités pour exaucer les voeux des administrateurs du système sans casser ce dernier.
dpkg-divert, voir La
commande dpkg-divert, Section 6.5.1.
equivs, voir Le paquet
equivs, Section 6.5.2.
update-alternative, voir Commandes de rechange, Section
6.5.3.
make-kpkg peut s'accomoder de beaucoup de chargeurs . Voir
make-kpkg(1).
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.
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.
Voir Le noyau Linux et Debian, Chapitre 7.
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.
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.
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.
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 UTCosamu#at#debian.orggerbs#at#free.fr