Dans toutes les distributions modernes, il y a un système de paquets. Mais d'abord, qu'est ce que c'est ? En gros, un paquet, c'est un programme prêt à s'installer et surtout à se désinstaller proprement sur votre système. La définition de « proprement » est régie par des règles très strictes sous Debian : la « Debian policy ». Ne pas respecter ces règles est une bonne façon de se faire éliminer de l'archive officielle. Pour les simples utilisateurs, c'est la garantie que tout devrait bien se passer.
Notons d'emblée que son système de paquets est l'un des points les plus forts
de Debian, et qu'il constitue à lui seul une bonne raison de prendre Debian au
lieu d'une autre distribution (ou de lire cette section jusqu'à la fin, pour
comprendre de quoi il retourne :). Et ça sera furieusement nouveau pour ceux
qui arrivent de Windows. Souvenez-vous de l'époque où vous regardiez,
impuissant, votre répertoire \windows
se remplir de DLL, sans
savoir lesquelles vous pouviez effacer sans risque. C'est contre ce fléau, et
bien d'autres, que les systèmes de paquets ont été inventés.
Dans les faits, tous les paquets ne sont pas des programmes. Certains sont des
bibliothèques (library, en anglais, mais c'est un faux ami). C'est à dire des
bouts de codes inutiles en eux mêmes (vu qu'on peut pas les utiliser
directement), mais indispensables au bon fonctionnement des autres programmes.
L'époque où chaque programmeur devait réinventer la roue est révolue.
Maintenant, on se sert de bibliothèques. Dans le même ordre d'esprit, certains
paquets ne contienne que de la documentation, et aucun programme ou
bibliothèque. Il existe même des paquets ne contenant rien du tout. On les
appelle des méta-paquets. À quoi servent-ils me demandez vous ? Ils sont là
pour grouper les paquets par sujet. Ainsi, il existe un paquet
task-games
, qui dépend d'une sélection de jeux. Comme ça, pour
les installer, pas besoin de se souvenir du nom de chacun, il suffit
d'installer le méta-paquet pour voir s'installer tous les jeux dont il dépend.
Maintenant, étudions ce qu'il y a dans un paquet. En gros, il contient deux
types d'informations : le programme à installer, et toutes les informations qui
vont permettre de l'installer. Parmi ces informations, on trouve
l'architecture. Debian est disponible pour différents processeurs (Intel et
compatible, Sparc, PowerPC... La liste s'agrandit d'année en année), et un
programme compilé pour un processeur ne peut pas fonctionner sur un autre. Il
est donc important de savoir pour quel processeur (on dit donc « architecture
») le paquet est prévu. D'autres informations très importantes sont les
conflits et les dépendances. On a vu que certains programmes ont besoin de
certaines bibliothèques pour tourner. C'est une dépendance. Mais il arrive
aussi que deux paquets ne puissent pas fonctionner tous les deux s'ils sont
tous les deux installés. C'est un conflit. Par exemple, il y a différentes
façons de discuter avec l'imprimante. Il y a donc différents programmes qui
font ce boulot (lpr et lprng, pour ne pas les citer). Mais il est clair qu'on
va pouvoir utiliser un seul de ces programmes à un instant donné, sinon, ils
parleraient tous les deux en même temps à l'imprimante qui serait sans doute un
peu déboussolée. Il y a d'autres types de dépendances. Les recommandations.
Ça peut marcher sans, mais c'est tout de même mieux avec. Il y a encore
d'autres types de dépendance, mais il n'est pas nécessaire de les connaître
pour l'instant. Si toutefois vous êtes un petit curieux et que vous voulez
absolument en savoir plus, veuillez vous reporter au document de référence,
contenu dans le paquet packaging-manual
. Dans la version que j'ai
sur ma machine, il s'agit du Chapitre 8 : Declaring relationships between
packages. Et si vous êtes allergique à l'anglais, mais curieux quand même,
installez le paquet doc-debian-fr
, et regardez le manuel
packaging.fr. L'ennui, c'est que la version anglaise dont je dispose date du
1999-11-22 et la version française du 15 octobre 1998...
Si vous êtes du genre à ne pas me croire sur parole, l'extension classique des
paquets Debian est bien sûr .deb, et si vous utilisez le programme mc, vous
pouvez voir le contenu de l'un d'entre eux en appuyant sur entrée après l'avoir
sélectionné. Le répertoire CONTENTS
contient le programme lui
même, et tout le reste est les informations sur le paquet. Faites F3 sur les
différents fichiers pour voir ce qu'il y a dedans (et F10 pour sortir du
visualiseur après). Bonne lecture.
Bien, maintenant que nous savons un peu mieux ce que c'est qu'un paquet, voyons le minimum à savoir pour les utiliser. Tout d'abord, seul l'utilisateur root (dieu sous linux) a le droit de changer les paquets installés sur le système. Ensuite, il nous faut un programme pour installer et désinstaller les paquets. Debian, dans sa grande mansuétude, nous fournit trois outils (au moins) pour le faire.
dpkg
: C'est en fait le seul habilité à faire le boulot effectif
d'installation/désinstallation. Les autres ne sont que des sur-couches pour
rendre son usage plus agréable. Un dpkg --help|pager est
indispensable pour savoir s'en servir. Sachez juste qu'à moins de préciser une
option du type --force-*, il ne vous laissera pas faire de bêtise
trop grave. Mais prudence quand même, c'est un outil puissant. Suffisamment
pour vous causer des ennuis si vous vous tirez dans le pied.
dselect
: C'est une interface graphique (en mode caractère) très
pratique quand on sait s'en servir. Dans le cas contraire, certains vont
jusqu'à dire que c'est un programme pour vénusien halluciné. De plus, il tend
à se faire de plus en plus rare, car il est remplacé par l'autre solution :
apt-get
(dans le paquet apt) : il est magique. Il sait aller
chercher sur le web ou les CD les paquets dont vous avez besoin, et les
installer (en demandant à dpkg, bien sûr). Il a un seul défaut, pour
l'instant, il n'a pas d'interface graphique fonctionnelle.
Ok. Nous avons fini ce tour d'horizon à la fois suffisamment long pour avoir fait fuir certains lecteurs et trop court pour vous apprendre à gérer les paquets. Mais vous apprendrez cela dans la documentation adéquate : les éternels <programme> --help, man <programme> et autre info <programme>. Place aux questions classiques, maintenant.
Q: J'ai besoin d'un paquet qui ne se trouve pas dans la distribution de Debian. Où chercher ?
R: LA page à chercher pour ce genre de problème est la liste
non-officielle des sources non-officielle pour apt
. Si le paquet
cherché n'est pas là, il y a de grandes chances pour qu'il n'existe pas.
Un exemple de paquets souvent cherchés, c'est KDE. On peut le trouver à deux endroits:
deb ftp://ftp.kde.org/pub/kde/stable/1.1.2/distribution/deb/potato i386/ deb ftp://ftp.kde.org/pub/kde/stable/1.1.2/distribution/deb/slink i386/
deb http://kde.tdyc.com/ slink kde kde2 contrib rkrusty deb http://kde.tdyc.com/ potato kde kde2 contrib rkrusty
Q: Comment trouver un paquet par son nom, ou le paquet contenant un fichier donné ?
R: Cette question a plusieurs réponses, qui dépendent un peu de ce qu'on veut faire. Elles sont ici rangées de la moins générale à la plus générale.
Pour chercher un paquet contenant le fichier toto :
dpkg -S toto
Pour chercher le paquet toto :
dpkg -l toto
On peut même raffiner, et chercher tous les paquets ayant toto dans leur nom :
dpkg -l "*toto*"
En fait, ce programme fait plus ou moins la même chose que dpkg, mais il le fait bien plus vite. Pour plus d'information, voir : man dlocate ou dlocate --help
Apt-cache permet de rechercher rapidement parmi la liste des paquets disponibles. Son utilisation la plus courante est avec l'option search qui prend une expression rationnelle en paramètre.
apt-cache search emacs
affichera tous les noms des paquets, avec une description courte, dont le nom ou la description contient le mot emacs. Pour faire une recherche uniquement sur les noms des paquets, ajouter l'option --names-only :
apt-cache search --names-only emacs
apt-cache show <nom-paquet> fournira une description plus complète du paquet nommé.
Connecte-toi en irc au serveur irc.debian.org, canal #debian, puis : (avec toto le nom du paquet ou du fichier)
<mt> /msg dpkg !find toto <dpkg> toto is in package: blablabla
Si tu ne veux pas chercher dans la distribution instable, mais dans, par exemple slink, c'est pas plus dur :
<mt> /msg dpkg !find toto slink
Les dites
pages
. C'est tout bien expliqué (en anglais :) sur ces pages.
Dans ce qui suit, il y a deux méthodes on ne peut plus générales. La première est pour chercher un paquet (quoi qu'on puisse l'adapter pour chercher un fichier de configuration sans problème), et la deuxième est pour chercher un fichier.
Ces fichiers sont cachés dans le répertoire /var/state/apt/lists.
Exemple : Chercher le paquet cddb
grep -h -15 "Package: cddb" /var/state/apt/lists/* | pager
Chez moi, ça donne (entre autres déchets) :
:Package: cddb -Version: 2.5-1 -Priority: optional -Section: sound -Maintainer: Wichert Akkerman <wakkerma@debian.org> -Depends: libc6 (>= 2.1) -Conflicts: kdemultimedia (<=2:980419-b4-1) -Replaces: xmcd (<=2.3-1) -Architecture: i386 -Filename: dists/potato/main/binary-i386/sound/cddb_2.5-1.deb -Size: 39770 -MD5sum: ed1842f681c80570c7938e7b4ba00f0b -Description: CD DataBase support tools - This package provides a location for programs to store files from the - CDDB in and contains a simple program to query CDDB servers. -source: xmcd -installed-size: 67
<point de montage du cd>/dists/<distribution>/Contents-<arch>.gz
Par exemple, chez moi c'est :
/mnt/cdrom/dists/stable/Contents-i386.gz
<archive ftp>/dists/<distribution>/Contents-<arch>.gz
Ce qui donne, sur mon miroir favori,
ftp://ftp.paris.fr.debian.org/pub/Distributions_Linux/Debian/dists/potato/Contents-i386.gz
la liste des
sources non officielles pour apt
, et je n'ai trouvé aucune source
mettant ce fichier à disposition. Mais c'est pas une preuve...
Il y a un beau petit texte explicatif au début de ce fichier (en anglais :). Mais pas besoin de longues phrases, on fait :
zgrep <fichier cherché> <fichier Content>
Parfois, on se retrouve avec un paquet pas encore installé, mais déjà cassé. La solution préconisée par dpkg est de le réinstaller complètement. Mais ce n'est pas toujours possible, et voici une autre idée, très bidouillatoire et potentiellement dangereuse, puisqu'elle consiste à aller trifouiller dans les fichiers de dpkg sans le tenir au courant :
Encore une fois, mettre son nez comme ça dans les fichiers de dpkg, c'est mal. Cette solution ne devrait être utilisée qu'en dernier ressort.
Très simple, il suffit de demander à apt de réinstaller ce paquet:
apt-get update apt-get install <paquet>
(Avec l'active participation de Frédéric Petit <Frederic.Petit@univ-mlv.fr>)
Avant de se demander comment recompiler un paquet à partir des sources, on peut se demander pourquoi.
À cela, deux raisons principales :
En gros, le principe de la recompilation tient en trois étapes :
Il y a deux méthodes : l'ancienne, qui consiste à télécharger les fichiers à la
main, et de les décompresser de la même manière. La nouvelle consiste à
demander à apt
de le faire.
Pour suivre l'ancienne méthode, il suffit d'aller sur votre moteur de recherche préféré pour les paquets Debian, et de taper le nom du paquet désiré. Le serveur vous propose alors évidemment de rapatrier le paquet pré-compilé, mais, ici, ce sont les sources qui nous intéressent. Et il y a trois fichiers à récupérer : <paquet>.dsc, <paquet>.diff.gz et <paquet>.orig.tar.gz, sachant que le nom du paquet des deux premiers fichiers contient non seulement la version du programme, évidemment, mais aussi son numéro de version pour Debian.
Une fois rapatriés, vous les décompressez, par exemple dans /usr/src. Ne faites pas la décompression en tant que super-utilisateur, mais rajoutez plutôt votre nom d'utilisateur au groupe src (voir Questions sur les permissions, Chapter 8). Ainsi vous pourrez y décompresser les sources et faire ce que vous voulez, sans grand risque.
Enfin, pour décompresser les paquets, il faut utiliser la commande dpkg-source(1), avec l'option '-x' pour les extraire. Cette commande a pour résultat de créer un répertoire, du nom du paquet en question.
Ce répertoire est tout à fait classique et semblable à celui que l'on aurait obtenu à partir d'un « tarball », à ceci près que dans notre cas, on y trouve un répertoire debian/.
Si vous préférez utiliser apt
, il suffit (en supposant que vous
avez des lignes commençant par deb-src dans votre
sources.list) de taper :
apt-get source <paquet>
et apt
se charge de tout : localiser les fichiers, les
télécharger, et les décompacter sous vos yeux ébahis. Si vous ne souhaitiez
pas les décompacter automatiquement, il faut préciser l'option
--download-only.
Reste à compiler le paquet.
On a en fait trois possibilités ici.
La première est de tout faire à la main : on fait un « ./configure » (la plupart des programmes utilisent autoconf(1) aujourd'hui), suivi d'un « ./debian/rules binary ».
La seconde méthode est d'utiliser une commande toute faite pour cela, à savoir dpkg-buildpackage(1), sans argument.
Dans les deux cas, le système vérifie si vous êtes bien le super-utilisateur. Or justement, normalement, vous ne l'êtes pas. Comment contourner ce problème ? En utilisant la commande fakeroot(1). Pour cela, il suffit juste de faire précéder la commande de compilation par fakeroot :
fakeroot ./debian/rules binary
ou
fakeroot dpkg-buildpackage
Vous obtenez ainsi un paquet nom_pack_arch.deb, où arch représente le type de processeur que vous avez (i386 pour les PC Intel), qui se trouve dans le répertoire /usr/src, donc en dehors du répertoire de compilation.
La troisième méthode est de demander à apt
de tout faire :
l'animal, non content de savoir télécharger les sources et de décompresser
l'archive, sait aussi les recompiler à la volée. Si vous précisez l'option
--compile sur la ligne qui demande de télécharger les sources,
apt
lance automatiquement dpkg-buildpackage
... La
magie de la technologie moderne !
Reste plus qu'à l'installer.
Bon, là, pas besoin de tergiverser, j'espère ;-), c'est comme d'habitude :
dpkg --install nom_pack_arch.deb
Et le tour est joué.
Il est très facile d'installer des tonnes de programmes que l'on n'utilise jamais. La question est donc comment connaître les paquets que je peux désinstaller sans risque ?
En effet, par le jeu des dépendances, on ne peut pas désinstaller n'importe
quoi n'importe comment. Par exemple, si l'envie me prend de désinstaller la
bibliothèque la plus importante du système, j'ai nommé libc
, dans
le meilleur des cas, dpkg
ne va pas me laisser faire, sous
prétexte que pleins de paquets en dépendent (quasi tous, en fait). Si j'ai
moins de chance (et que je suis assez bête pour forcer la désinstallation, par
exemple), aucun programme ne fonctionnera. Peut-être même que
dpkg
va désinstaller avec tous les paquets qui dépendent de
libc
(comme je l'ai dit, quasi tous). Je sais pas exactement ce
qui se passe si je fais cette méga bourde, mais je suis pas pressé de savoir.
Donc, il ne faut supprimer que des paquets dont aucun paquet ne dépend (que
l'on nommera dans la suite les paquets terminaux). On peut les désinstaller
sans casser le système, mais évidemment, si on désinstalle ainsi un paquet
terminal, mais utile quand même, ce n'est pas très malin. Par exemple, j'aime
bien programmer en caml, donc le paquet ocaml
peut bien être
terminal, je ne vais pas me priver de mon compilateur favori pour autant...
Voici comment on peut vouloir procéder pour se débarrasser de certains paquets
superflus :
Il existe heureusement un programme, pkg-nodep
dans le paquet
pkg-order
, qui liste les paquets terminaux. On peut par exemple
écrire dans un fichier la liste de ces paquets avec la commande :
pkg-nodep > liste-des-nodeps
Plusieurs méthodes :
Si on est pas sûr, le programme dpkg-repack
peut être utile pour
réempaqueter les paquets pour les stocker avant de les retirer (voir la page de
manuel associée : man dpkg-repack).
Il s'agit des traductions des messages des programmes internationalisés. Ils
sont présents dans le répertoire /usr/share/locale
, rangés dans
des sous-répertoires, un par langue. Par exemple, si personne ne parle le
russe dans votre entourage, vous pouvez vous passer de ru*
(et
gagner près d'un Mo). Attention à garder en*
, sinon ça risque de
ne plus marcher du tout, et fr*
, sinon, vous n'aurez plus les
messages en français...
Le fait qu'il faille faire cela à la main est un gros défaut de Debian (mais
les autres distributions ne font pas mieux sur le sujet ;). Il faut faire le
propre à la main après chaque mise à jour (qui ne devraient pas être si
courantes, après tout). Autre mauvaise nouvelle, je ne sais pas si
dpkg
va aimer le tour de passe passe lors de la prochaine mise à
jour. Je ne pense pas qu'il y ait de problème pour réinstaller le paquet (pour
avoir une version plus récente, par exemple), mais j'ignore ce qui se passe si
on essaye de retirer le paquet. (FIXME: je teste ce cas sur la machine sur
laquelle j'ai fait cette manip, et on en recause)
Remarque préliminaire : ce qui suit est vrai si on utilise l'exécutable
tetex
pour faire du LaTeX (c'est vrai par défaut avec Debian).
En fait, il y a trois choses à faire pour cela :
Le plus raisonnable semble être de choisir /usr/local/share/texmf comme racine, puis de prendre le même type d'arborescence que ce qu'on trouve dans /usr/share/texmf pour la suite. Par exemple tex/latex/lettre pour mettre la classe lettre.
Pour cela, on modifiera le fichier de configuration
/etc/texmf/texmf.cnf
. Si on a choisi ce qui précède, il faut
ajouter :
TEXMFLOCAL = /usr/local/share/texmf TEXMF = {!!$TEXMFMAIN,!!$TEXMFLOCAL}
Il suffit pour cela de lancer l'utilitaire texhash
Vous l'aurez sans doute remarqué, il est plus courant de trouver des paquets faits pour les distributions basées sur RedHat que pour celles basées sur Debian. La tentation est donc grande de récupérer ces paquets, et d'essayer de le faire.
Mais avant d'aller plus loin, je me dois de vous déconseiller fortement de faire cette manipulation. En effet, pour être un apôtre Debian parfaitement honnête (sic), les paquets RedHat sont particulièrement mal faits. Il est autorisé de faire des trucs pas propres comme des dépendances non pas sur un beau paquet, mais sur un fichier. Et on ne connaît pas la version d'un fichier, par exemple. Et les noms des paquets RedHat ne sont pas les mêmes. Bref, c'est à faire en dernier recours. Certains préfèrent même recompiler un programme plutôt que d'installer un paquet RedHat...
Mais bon, si vous voulez vraiment installer un paquet RedHat (ou Slackware,
d'ailleurs, c'est encore pire à mon avis, mais c'est possible), il vous faut
utiliser le paquet alien
, qui vient avec tout plein de
documentation bien faite...
Je suppose qu'il faut commencer par expliquer pourquoi la question se pose... Le problème, c'est que ce programme est commercial et non libre. Il fût même une époque où les sources n'étaient pas disponibles. À l'époque, il fallait télécharger les binaires du programme sur le site de Netscape, et un paquet de Debian se chargeait de l'installer où il faut pour faire les choses proprement (on appelle ce genre de programme des wrappers). Heureusement, cette époque est terminée. Maintenant, il y a des paquets qui contiennent netscape, et on n'a plus besoin de télécharger quoi que ce soit du site de Netscape (ni d'utiliser de wrapper, même s'il semble encore présent dans certaines distributions). Mais la vie n'est pas rose pour autant : ce programme n'est toujours pas assez libre pour pouvoir être placé directement dans la partie « main » ou même « contrib » de Debian. Il est relégué dans la partie « non-free ». Malheureusement, la plupart des revendeurs de CD ne mettent pas cette partie de Debian sur leurs CDs, pour être sûrs de ne pas avoir de problème. Il faut donc utiliser apt-get (ou autre méthode équivalente) pour récupérer sur le réseau les paquets qu'il faut.
La question suivante est : quel paquet choisir ? Il y a moult paquets netscape
dans Debian, et tous ne sont pas nécessaires (ni même compatibles. On ne peut
pas tous les installer à la fois). Le plus simple est d'installer le
méta-paquet netscape
(un paquet vide qui n'est là que pour avoir
des dépendances sur les bons paquets). Il dépend de deux paquets, au choix :
navigator
, qui ne contient que l'arpenteur (browser pour
l'académie française) ou communicator
, qui contient l'arpenteur,
le gestionnaire de mail, celui de news, et tout ce que contient l'office
netscape. À vous de choisir.
En fait, KDE n'est pas dans Debian potato, pour des histoires de licences : Au moment où potato est sortie, il y avait toujours un problème de licence avec KDE. En pratique, KDE est distribué sous licence GPL. Il aurait fallu ajouter une exception pour autoriser la liaison dynamique avec la bibliothèque QT de l'époque, qui était éventuellement libre, mais de toute façon incompatible avec la GPL (donc pas de mélange). La GPL exige en effet que la bibliothèque dynamique avec laquelle le programme est lié soit sous licence compatible avec la GPL (ie que l'on puisse relicencier le code sous la GPL). C'est le cas de la licence X, BSD sans clause d'avertissement, la GPL (bien sûr), la LGPL. On a aussi le droit pour des bibliothèques standard, mais elles ne doivent pas être livrées en même temps que le programme considéré. Donc Debian ne pouvait pas distribuer KDE (et les autres distributions étaient dans l'illégalité). Le seul cas où il est légal d'installer KDE est lorsque Qt fait partie de la distribution considérée, et que l'on installe KDE à part. Ça tombe bien, Qt, elle, était dans Debian.
Et les auteurs de KDE, qui ont promis il y a longtemps de faire explicitement l'exception pour Qt 2.0 dans la licence de leur code ne l'ont pas fait. De plus, certains programmes comme kgv étaient dans l'illégalité pure et simple, du code GPL ayant été repris et les auteurs des programmes originaux ayant signifié qu'ils ne changeraient pas leur licence (sous-entendu : ils ne veulent pas autoriser leur code à être lié à une bibliothèque dynamique non GPL).
Donc pas de licence correcte, pas de KDE.
Mais bonne nouvelle, ces sombres histoires de licence sont terminées car la bibliothèque QT est maintenant distribuée sous licence GPL, et on peut donc trouver KDE dans Debian. Évidemment, ces changements ayant eu lieu après le gel de potato, il faut chercher KDE dans woody (qui n'est pas la version STABLE de debian, ne l'oublions pas).
En attendant que Woody soit devenue stable, vous pouvez toujours aller faire un
tour sur le site de dédié à KDE dans
Debian
. (attention, ce n'est pas un site officiel de Debian).
Il arrive que suite à un problème, chaque fois qu'on installe un paquet, on ait un message du genre :
ldconfig: warning: can't open /lib/libNoVersion.so.1 (Aucun fichier ou répertoire de ce type), skipping
Si le fichier en question est un lien symbolique qui pointe vers rien, on peut soit l'effacer, soit le corriger (en l'effaçant, puis en le recréant, de façon à ce qu'il pointe vers la bonne destination).
Et comment savoir sur quoi le faire pointer, me demandez vous ? Il suffit de grep'er le fichier de contenu de Debian pour le savoir. Exemple :
zgrep /lib/libNoVersion.so.1 Contents-<architecture>.tar.gz
Pour plus d'informations sur ce fichier, voir la fin des Méthodes pour chercher n'importe quel paquet, Section 2.3.3.
Cette fonctionnalité est prévue, et il n'y a pas besoin de ruser. Il suffit de marquer le paquet « à garder » (on hold, en anglais). Pour ce faire, on peut soit :
echo "<paquet à garder> hold" | dpkg --set-selections
Comme on l'a vu plus haut, il est facile de déterminer si un fichier appartient à un paquet et si oui lequel avec la commande dpkg -S toto. Mais comment déterminer sur une arborescence entière quels fichiers manquent et quels fichiers ne devraient pas être présents ? La solution est l'utilisation de cruft.
cruft rapporte la différence entre la liste des fichiers qui devraient être installés selon la base et la liste de ceux réellement présents sur le disque. Il permet donc de faire du ménage ou de réinstaller des paquets détériorés.
Il est parfois utile d'installer un paquet qui n'existe que dans une distribution supérieure (et moins stable).
Par exemple le paquet gnumeric n'est pas présent dans la distribution testing car il dépend d'un paquet qui n'existe pas dans cette distribution. Il faut alors utiliser le paquet gnumeric de la distribution unstable. Cet exemple de gnumeric n'est valable qu'aujourd'hui (septembre 2001) mais ne le sera plus demain lorsque woody sera la distribution stable.
Les versions supérieures à 0.5.0 d'apt-get permettent de faire
cela simplement. Donc, si vous avez une patate ou plus ancien, il faudra
auparavant obtenir une version d'apt plus récente par un autre moyen (par
exemple sur le site de
Christian
).
Voici la marche à suivre pour cette opération :
deb http://ftp.fr.debian.org/debian unstable main contrib non-free deb http://ftp.fr.debian.org/debian-non-US unstable/non-US main contrib non-free
APT::Default-Release ``stable'';
apt-get update
apt-get install -t unstable paquet
apt-get install paquet/unstable
apt-get va alors installer le paquet et toutes ses dépendances. La différence entre les deux versions étant que dans le premier cas (avec «-t unstable»), les dépendances sont cherchées dans unstable, alors que dans l'autre cas (avec « /unstable »), les dépendances sont cherchées dans la distribution par défaut.
Les paquets utilisent maintenant des signatures MD5. On peut donc utiliser ces signatures pour vérifier que les fichiers installés sur le disque correspondent bien à ceux contenus dans le paquet. Pour ce faire, il suffit d'utiliser debsums. Voici quelques exemples d'utilisation :
debsums -s apt
debsums -s
À l'heure où ces lignes sont écrites, tous les paquets ne contiennent pas encore de signature. Pour obtenir la liste des paquets non signés, utiliser debsums -l.
Comme la plupart d'entre vous le sait, il s'agit du fichier où l'on précise à apt où il doit aller chercher les paquets.
Il est donc très important de bien configurer ce fichier, pour que les mises à jour soient assez rapides (ie, choix du bon miroir), et que les paquets installés soient ceux que vous voulez (ie, choix de la bonne distribution).
Régler ce fichier est l'un des premiers malheurs des nouveaux venus sous Debian. Pour ce faire, il est bon de lire la page du manuel en donnant la syntaxe : man sources.list. On peut aussi s'inspirer du fichier par défaut qui arrive avec apt, ou des fichiers d'exemples suivants :
Premier fichier pour avoir la distribution stable depuis des serveurs situés en Belgique :
deb ftp://ftp.linkline.be/pub/linux/debian potato main contrib non-free deb ftp://ftp.linkline.be/pub/linux/debian-non-US potato/non-US main contrib non-free
Autre exemple, pour avoir la distribution instable depuis des serveurs situés en France :
deb http://ftp.fr.debian.org/debian unstable main contrib non-free deb http://ftp.fr.debian.org/debian-non-US unstable/non-US main contrib non-free
Je rajoute ça pour pouvoir télécharger des sources avec apt-get source <paquet> :
deb-src ftp://ftp.fr.debian.org/debian unstable main contrib non-free
Et les utilisateurs de la version stable ne devraient se passer sous aucun prétexte des mises à jours de sécurité et des améliorations proposées :
deb http://security.debian.org stable/updates main contrib non-free deb ftp://ftp.fr.debian.org/debian dists/proposed-updates/ deb ftp://ftp.fr.debian.org/debian-non-US dists/proposed-updates/
(Il est conseillé de piocher les mises à jour de sécurité directement sur le serveur américain donné ici pour réduire encore le temps entre la découverte du trou de sécurité et l'installation du contre sur votre machine.)
Le plus souvent, quand on essaye de mettre un fichier des sources au point, apt râle qu'il n'arrive pas à télécharger les fichiers promis. C'est en général que l'on s'est trompé dans le chemin. Le plus simple est alors de prendre un client ftp, et d'aller voir quel est le bon chemin directement sur le site. Je veux dire que si j'ai mis dans mon fichier quelque chose comme :
[FAUX] deb ftp://ftp.fr.debian.org/debain unstable main contrib non-free
dans mon fichier de configuration, apt va se plaindre. Le plus simple est alors de pointer mon netscape sur ftp.fr.debian.org pour me rendre compte que le bon chemin est /debian et non /debain.
Voila, avec ces quelques exemples et pointeurs, je pense que vous devriez être capable de vous faire vous-même un fichier de sources aux petits oignons.
Voir aussi :Trouver un paquet non-officiel, Section 2.2
En général, on considère que le meilleur serveur est le plus rapide. Pour
mesurer la vitesse des différents serveurs, on peut utiliser le programme
netselect
.
Mais il faut aussi choisir un miroir à qui l'on puisse faire confiance (ie, exempt de paquets vérolés). Pour cela, le plus sage est sans doute de se limiter à des miroirs officiels. En cas de problème, on peut récupérer le md5sum du paquet sur un miroir officiel pour en vérifier l'authenticité.
La FAQ de la liste debian-user-french@lists.debian.org
15 avril 2002debian-user-french@lists.debian.org
mquinson@ens-lyon.fr
thierry.laronde@polynum.com
C.Martin@ipnl.in2p3.fr
Frederic.Petit@univ-mlv.fr