Installation des logiciels

État : {a_reli}

Retour au document principal

Pré-requis

Objectifs

Introduction

Commençons par un petit exemple de code. Même si nous n'avons pas besoin d'une compréhension avancée du langage C, ces exemples pourront vous aider à résoudre des situations courantes.

Bibliothèques statiques et partagées

Lorsque des fonctions sont souvent utilisées, elles sont stockées dans des bibliothèques. On peut alors lier du code qui utilise ces fonctions aux bibliothèques qui les contiennent pendant la compilation. Les bibliothèques peuvent être liées statiquement ou dynamiquement au code.

La compilateur gcc a de nombreuses options pour lier les les bibliothèques. Cependant, par défaut gcc lie les fichiers donnés à la ligne de commande qui ne comportent pas l'extension .c (seuls les fichiers .c sont traités comme du code).

Illustration : lien par défaut

gcc main.c Bonjour.o

Cette commande produit un fichier a.out exécutable lié statiquement à l'objet Bonjour.o.

Illustration d'une application liée statiquement (a.out) :

Schéma représentant une bibliothèque statique dans un fichier exécutable a.out

Bibliothèques statiques

Les bibliothèques statiques sont des archives de fichiers .o. Ces archives sont créées avec la commande ar et comportent une extension .a.

Illustration : ajout d'un fichier objet à une archive

ar rcs libfoo.a fichier1.o fichier2.o

Bibliothèques dynamiques / partagées

Une bibliothèque partagée est une bibliothèque qui est chargée par le programme quand celui-ci est exécuté. On dit également que la bibliothèque est chargée dynamiquement.

Illustration : Création d'une bibliothèque partagée :

gcc –c –fPIC Bonjour.c.c     crée le fichier objet
gcc –shared –W1,soname,libfoo.so.1 –o libfoo.so.1.0 Bonjour.o

L'option -fPIC génère du code indépendant de la position (PIC : Position Independent Code).

Illustration : compilation avec une bibliothèque partagée

gcc main.c libfoo.so.1.0

Cette commande produit un fichier exécutable a.out. Cependant, si vous essayez de le lancer, il vous affichera l'erreur suivante :

Illustration : Erreur due à une bibliothèque partagée non trouvée

./a.out: error while loading shared libraries: libfoo.so.1.0: cannot open shared object file: No such file or directory 

Cette erreur illustre ce qui se passe quand l'éditeur de liens n'arrive pas à trouver la bibliothèque dynamique libfoo.so.1.0. Nous verrons comme résoudre ce problème dans la prochaine partie.

Illustration d'une application liée dynamiquement (a.out) :

Schéma représentant le chargement d'une bibliothèque partagée au lacement d'un fichier exécutable a.out

Le processus chargé d'attacher une bibliothèque dynamique au lancement, appelé la liaison, est géré par l'éditeur de lien (ou linker) ld.so. Comment l'éditeur de liens sait où trouver libfoo.so ? La réponse à cette question se trouve juste en-dessous.

Attribution des noms aux bibliothèques partagées et chargement dynamique

Pour comprendre comment les bibliothèques sont gérées sous Linux, nous allons nous baser sur l'exemple ci-dessous.

Pour connaître les bibliothèques partagées nécessaires à l'exécution d'un programme, on utilise la commande ldd.

Exemple :

ldd a.out
        libfoo.so.1.0 => not found
        libc.so.6 => /lib/libc.so.6 (0x40028000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Vous noterez que libfoo.so.1.0 est introuvable. En effet, a.out doit charger dynamiquement cette bibliothèque mais l'éditeur de liens ld.so ne la connaît pas.

En fait l'éditeur de liens utilise une base de donnée appelée ldcache dont le contenu est de la forme :

soname =>/chemin/vers/bibliothèqe

La commande ldconfig -p permet d'afficher le contenu du ldcache :

ldconfig -p
        libaudiofile.so.0 (libc6) => /usr/lib/libaudiofile.so.0
        libaudiofile.so (libc6) => /usr/lib/libaudiofile.so
        libaudio.so.2 (libc6) => /usr/X11R6/lib/libaudio.so.2
        libattr.so (libc6) => /usr/lib/libattr.so       ..........

Le ldcache est généré à l'amorçage du système par la commande ldconfig. Par défaut, ldconfig examine les répertoires /lib et /usr/lib pour construire le ldcache.

Si d'autres répertoires contiennent des bibliothèques, comme /usr/local/lib, /opt/lib ou /usr/X11R6/lib, vous devez répertorier ces répertoires dans le fichier /etc/ld.so.conf pour informer ldconfig qu'il doit les prendre en considération lorsqu'il génère le cache.

Que se passe-t-il au lancement d'une application ?

L'application demande les bibliothèques dont il a besoin à l'éditeur de lien en utilisant le soname. Ensuite, l'éditeur de lien interroge le ldcache et associe le soname avec le chemin complet vers la bibliothèque, puis il établit le lien entre la bibliothèque et l'application.

Que se passe-t-il si le ld-cache ne contient pas le chemin complet vers la bibliothèque ?

En général, le programme n'arrive pas à se lancer et affiche un message d'erreur du type "cannot open shared object file: No such file or directory". Cependant, on peut aussi définir la variable globale LD_LIBRARY_PATH et lui assigner le nom du répertoire contenant la bibliothèque.

À partir de ça, nous savons comment résoudre le problème que nous avions rencontré avec notre programme en utilisant l'une des deux méthodes suivantes :

  1. Si vous devez tester temporairement le programme, définissez la variable LD_LIBRARY_PATH :

    export LD_LIBRARY_PATH=$(pwd)
  2. Si vous êtes administrateur et que vous souhaitez que la bibliothèque soit accessible à tout le monde, copiez le fichier libfoo.so.1.0 puis lancez ldconfig pour mettre à jour le ldcache.

Notes :

Remarque : Sur certaines distributions, ldconfig n'examine pas /usr/local/lib. il suffit d'ajouter le répertoire dans /etc/ld.so.conf et... redémarrer ?

Installation à partir des sources

Les projets open source sont souvent distribués sous forme d'archives tar. De nombreux environnements de développement (glade, kdevelopp, etc.) génèrent les fichiers qui facilitent la compilation et l'installation d'un projet.

Les archives non compressées

Les archives non compressées portent l'extension .tar. Par exemple, si le projet a été développé dans un répertoire appelé mon-projet-v.1/, alors la commande suivante archivera le répertoire avec ses fichiers et sous-répertoires :

tar c mon-projet-v.1/ > mon-projet-v.1.tar

ou

tar cf  mon-projet-v.1.tar mon-projet-v.1/

Comme la plupart des projets sont plutôt gros et téléchargeables sur Internet, on les trouve plus souvent sous une forme compressée.

Compression

Les trois outils utilisés pour la compression sont compress (ancien), gzip et bzip2. Contrairement au zip de windows, ces outils ne permettent de compresser que des fichiers. Cependant, comme une archive est un fichier qui contient toutes les informations pour pouvoir récupérer des répertoires, on peut utiliser ces commandes avec les archives. On appelle souvent les archives compressées "tarball".

Outil de compression

Outil de décompression'

Décompression cat

Extension de fichier

compress

uncompress

zcat

.Z

gzip

gunzip

zcat

.gz

bzip2

bunzip2

bzcat

.bz2

Exemples :

compress -v FICHIER1
FICHIER1:  -- replaced with FICHIER1.Z Compression: 40.29%

gzip  -v FICHIER2
FICHIER2:   53.4% -- replaced with FICHIER2.gz

bzip2 -v FICHIER3
FICHIER3:    2.326:1,  3.439 bits/byte, 57.01% saved, 605504 in, 260320 out.

Remarques :

  1. Lorsque vous compressez un fichier, l'extension .Z, .gz ou .bz2 est ajoutée au nom du fichier
  2. Ces commandes de compression ne fonctionnent qu'avec des fichiers, pas avec des répertoires
  3. On ne peut compresser qu'un fichier à la fois (pas de caractère générique !)

On peut également utiliser les commandes zcat et bzcatpour décompresser des fichiers, cependant les fichiers décompressés sont envoyés à STDOUT donc il est nécessaire de faire une redirection :

zcat FICHIER.Z > FICHIER1

Archives et compression

Outil de compression

Option de tar

Extension de l'archive

compress

Z

.tar.Z ou .tgZ

gzip

z

.tar.gz ou.tgz

bzip2

j

.tar.bz2

Le tableau précédent présente les options de tar Z,z et j qui font appel aux outils de compression appropriés lorsque c'est nécessaire.

Les deux exemples suivants sont équivalents :

tar cf  mon-projet-v.1.tar mon-projet-v.1/
bzip2  mon-projet-v.1.tar

tar cjf  mon-projet-v.1.tar.bz2 mon-projet-v.1/

Utilisation de tar

Nous savons désormais comment créer des archives. Il nous reste à connaître les options les plus courantes de tar.

Opération

Création

Extraction

Test

Options minimales

c ou cf

xf

tf

Autres Options

v,Z,z,j

v,Z,z,j

v,Z,z,j

Exemples : extractions

tar xvjf monprojet-v.1.tar.bz2
tar xzf autre-projet-v.2.0.tar.gz

Exemples : tests

tar tjf monprojet-v.1.tar.bz2
tar tzf autre-projet-v.2.0.tar.gz

Exemples alternatives utilisant zcat ou bzcat

bzcat monprojet-v.1.tar.bz2 | tar xf -
zcat autre-projet-v.2.0.tar.gz | tar tf -

Fichiers courants dans les sources des projets

Une fois l'archive d'un projet extraite, vous devriez trouver les fichiers suivants :

Compilation du projet

Si les fichiers que nous venons de voir sont présents, alors vous avez une bonne chance de pouvoir installer le programme sur votre ordinateur en suivant les étapes suivantes :

./configure
make
make install 

Il est très fortement recommandé de lancer ./configure et make en utilisateur normal. make install ne peut être lancé qu'en tant que root pour les répertoires d'installation protégés en écriture (/usr et /usr/local).

Le script ./configure a de nombreuses options. Pour une installation personnalisée, consultez ces options avec :

./configure –-help 

RPM : RedHat Package Manager

La plupart des distributions Linux utilisent un système de gestion de paquets pour installer, mettre à jour ou rechercher des programmes. Les systèmes de gestion de paquets Debian et RPM sont les plus populaires. Nous verrons dpkg et les outils Debian dans la prochaine partie.

Illustration : Fonctions d'un gestionnaire de paquets

Schéma présentant différentes fonctions d'un gestionnaire de paquets (installation, requêtes, vérification de signature...)

Conventions de noms pour les paquets

Il n'y a pas de convention stricte, mais la plupart des paquets rpm sont sous la forme :

nom-version_programme-version_paquet.architecture.rpm 

L'architecture indique au choix le type d'architecture système du binaire (i386, ppc, ia64, noarch,...) ou si le paquet contient les sources du programme (src).

Modes majeurs ou mineurs

Suivant leur place dans la ligne de commande, les options changent de signification. rpm fait la distinction entre la première option et les suivantes.

La première option donnée à rpm est son mode majeur. Par exemple dans la commande rpm -iv A.rpm, l'option "i" est l'option majeure qui entrainera l'installation du paquet A.

De même, une option qui n'est pas en première position est en mode mineur. par exemple dans rpm -qpi, l'option "i" est en mode mineur et récupèrera des informations sur le paquet A comme son auteur et son type de licence.

Voici les modes majeurs pour rpm :

Option courte

Option longue

Description

-i

--install

Installe le paquet

-U

--update

Met à jour (update) ou installe le paquet

-F

--freshen

Met à jour uniquement les paquets installés

-V

--verify

Vérifie la taille, les signatures MD5, les permissions, les types, etc.

-q

--query

Effectue des requêtes sur les paquets installés et désinstallés, ou sur des fichiers

-e

--erase

Désinstalle le paquet

Et voici les modes mineurs pour rpm :

Option courte

Description

a

s'applique à tous les paquets installés

c

avec q : liste les fichiers de configuration

d

avec q : liste les fichiers de documentation

f

avec q : recherche le paquet qui a installé le fichier donné

h

Affiche 50 marques de hachage quand l'archive du paquetage est déballée

i

avec q : affiche les informations sur un paquet

l

avec q : liste les fichiers et répertoires d'un paquet

p

avec q : interroge un paquetage <fichier_paquetage> non installé

v

bavard

Modes de recherche

Il y a trois types de recherches : les paquets non installés, les paquets installés et les fichiers.

Type de recherche

Option

paquet (fichier rpm)

-qp

paquet installé

-q

fichier (sur le système)

-qf

D'autres options vous permettent d'obtenir des information sur tous les fichiers installés -l, la documentation -d, les fichiers de configuration -c, etc.

Considérons par exemple le paquet routed-0.17.i386.rpm. Nous pouvons faire une requête sur le paquet et lister son contenu avant l'installation avec l'option -l :

rpm –qpl routed-0.17.i386.rpm 

Une fois le paquet installé, on peut interroger le paquet avec :

rpm –ql routed-0.17     ou
rpm –ql routed 

Enfin, si nous voulons trouver le nom du paquet qui a installé le fichier /usr/sbin/routed, on interrogera la base de données de rpm avec :

rpm –qf /usr/sbin/routed 

Options spéciales

--nodeps

Ne pas vérifier les dépendances avant d'installer, mettre à jour ou de désinstaller les paquetages

--force

force une mise à jour

--test

n'installe pas ou ne met pas à jour, affiche juste les infromations sur stdout

--requires PAQUET

avec q liste les paquets dont dépend ce paquet

--whatrequires CAPACITÉ

avec q liste les paquets qui dépendent de ce paquet

Signatures des paquets

Vous pouvez vérifier la signature de chaque paquet distribué comme partie d'un projet. Par exemple, pour récupérer les clés de tous les développeurs impliqués dans le projet Fedora, il vous suffit de faire (seulement une fois) :

rpm –-import /usr/share/rhn/RPM-GPG-KEY-fedora

Vous pouvez désormais télécharger n'importe quel paquet à partir d'un mirroir FTP des RPMs du projet. Par exemple nous avons téléchargé zlib-1.2.1.1-2.1.i386.rpm à partir du sous-répertoire Fedora de ftp.mirror.ac.uk. Nous pouvons vérifier l'authenticité du fichier avec :

rpm --checksig /home/adrian/zlib-1.2.1.1-2.1.i386.rpm
/home/adrian/zlib-1.2.1.1-2.1.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Intégrité des paquets

La commande suivante vérifie l'intégrité du paquet bash :

rpm –V bash

Cette commande ne nous retourne rien. Si nous tapons les commandes suivantes en tant que root :

chown bin /bin/bash
chmod 775 /bin/bash

Si nous re-vérifions l'intégrité du paquet bash, cette fois-ci nous avons :

rpm –V bash
.M...U..   /bin/bash

Le gestionnaire de paquet a comparé l'état de chaque fichier du paquet bash avec l'état de ces fichiers stocké dans sa base de données. Les modifications sur /bin/bash ont été identifiés.

Il est possible de faire un contrôle d'intégrité sur tous les paquets installés sur le système en ajoutant l'option "a" (--all) après "V" (--verify).

L'option --verify effectue un certain nombre de tests sur chaque fichier. Les caractères suivants permettent d'identifier les erreurs :

Caractère retourné

Description de l'erreur

.

le test s'est déroulé avec succès

||?||le test n'a pas pu être effectué|

S

la taille du fichier a changé

M

le mode de permission ou le type de fichier a changé

5

le hachage MD5 du fichier a changé

D

le code majeur/mineur du périphérique ne correspond pas

L

le lien symbolic est cassé

U

le propriétaire du fichier a changé

G

le groupe propriétaire du fichier a changé

T

la date de modification (mtime) a changé

Pour aller plus loin : construire des paquets RPM (n'est pas au programme des LPIs)

/!\ : Ce paragraphe ne fait pas partie des objectifs pour l'examen LPI 101. En suivant cette partie, vous rencontrerez peut-être des problèmes avec l'option --rebuild. Ce problème est du au fait que les nouvelles versions de RPM utiliser rpmbuild au lieu de rpm pour reconstruire des paquets.

Le code source de quantité de paquets RPM est également disponible en tant que paquet RPM est peut être utilisé pour construire un paquet binaire. La convention pour l'attribution du nom de fichier est :

nom-version_programme-version_paquet.src.rpm

Ces paquets contiennent au minimum deux fichiers : l'archive tar avec le code source et un fichier spec. Le fichier spec contient les instructions pour les appliquer les rustines (patchs), compiler et construire les paquets RPM. S'il faut appliquer un patch avant de compiler le paquet, alors le patch est inclut dans le paquet source.

Il y a trois méthodes pour construire un paquet RPM. Nous partirons d'un paquet nommé nom-version_programme-version_paquet.src.rpm.

Pour commencer, vous aurez besoin d'installer le paquet rpm-build :

Gestion des paquets Debian

Les systèmes basés sur Debian utilisent le gestionnaire de paquets propre à Debian en lieu et place de la gestion des paquets RPM. Le gestionnaire de paquet Debian est plus rigoureux est plus configurable que les rpm, mais pour des raisons historiques est moins largement utilisé (NdT : peut-être encore vrai au moment de la rédaction du document mais ça me semble beaucoup moins vrai aujourd'hui).

L'approche utilisée pour la gestion de paquets sous Debian est très proche de celle des RPMs. La comande correspondant à "rpm" sur Debian est "dpkg".

Conventions de noms pour les paquets

De même que pour les RPMs, les paquets Debian sont des fichiers appelés comme suit :

nom_version-versionpaquet_architecture.deb

La version du paquet indique la version Debian de la version du logiciel et l'architecture indique l'architecture du système (i386, sparc, all).

dpkg

dpkg est l'outil de base pour installer, construire, supprimer et gérer les paquets Debian. Cependant, on utilise plus souvent d'autres programmes qui contrôlent dpkg pour la gestion des paquets : apt, dselect (NdT : aptitude). dpkg prend plusieurs paramètres dans la ligne de commande : une action et zéro ou plusieurs options. Le paramètre <action> dit ce que dpkg doit faire et les options modifient l’action d’une manière ou d’une autre.

dpkg conserve des renseignements utiles sur les paquets disponibles. Cette information est divisée en trois classes : les états, les états de la sélection et les drapeaux. La modification de ces valeurs est principalement dévolue à dselect.

États des paquets

État

Description

installed

Le paquet est dépaqueté et correctement configuré.

half-installed

Le paquet est dépaqueté et la configuration a commencé mais, pour une quelconque raison, ne s’est pas terminée.

not-installed

Le paquet n’est pas installé sur le système.

unpacked

Le paquet est dépaqueté mais n’est pas configuré.

half-configured

Le paquet est dépaqueté et la configuration a commencé mais, pour une quelconque raison, ne s’est pas terminée.

config-files

Seuls les fichiers de configuration du paquet existent sur le système.

Drapeaux des paquets

Drapeau

Description

hold

dpkg laisse de côté un paquet marqué hold, à moins qu’il ne soit lancé avec l’option de forçage --force-hold.

reinst-required

Un paquet marqué reinst-required est défectueux et demande une réinstallation. dpkg ne peut supprimer de tels paquets, à moins qu’il ne soit lancé avec l’option de forçage --force-reinstreq.

Actions

Le cœur du fonctionnement de dpkg est le paramètre <action>. Le tableau suivant résume les principales actions de base dont vous êtes succeptibles d'avoir besoin.

Action

Description

-l

Affiche la liste des paquets installés sur le système, ou correspondant à un motif si précisé. Les trois premiers caractères de chaque ligne indiquent l'état, l'état de sélection et le drapeau pour le paquet

-s

Donne l’état du paquet indiqué

-I

Affiche des renseignements sur un paquet (fichier .deb)

-L

Affiche la liste des fichiers installés qui appartiennent à paquet

-S

Affiche le paquet qui inclue le fichier spécifié

-i

Installe ou met à jour et configure un paquet à partir d'un fichier .deb

--unpack

Dépaquète (uniquement) un paquet à partir d'un fichier .deb

--configure

Reconfiguration d’un paquet dépaqueté. Si l’on donne l’option -a ou --pending au lieu de paquet, tous les paquets dépaquetés mais non configurés sont configurés

-r

Supprime un paquet installé. L’action -r ou --remove supprime tout sauf les fichiers de configuration

-P

L’option -P ou --purge supprime tout, y compris les fichiers de configuration

--get-selections

Obtient la liste des sélections des paquets, et l’envoie sur la sortie standard

--set-selections

Modifie la liste des sélections des paquets en lisant un fichier sur l’entrée standard

Options

Toutes les options peuvent être soit précisées à la ligne de commande ou dans le fichier de configuration de dpkg /etc/dpkg/dpkg.cfg. Chaque ligne du fichier de configuration est soit une option (la même que le paramètre de la ligne de commande mais sans les "-"), soit un commentaire (commençant par "#").

Option

Description

-force-quelque-chose

Force dpkg à exécuter une action anormale (par exemple, ignorer les informations de dépendances --force-depends ou effectuer une mise à niveau inférieure avec --force-downgrade)

--refuse-quelque-chose

Refuser une action "normale" de dpkg

--ignore-depends

Ne tient pas compte de la vérification des dépendances pour les paquets spécifiés

--no-act

Faire tout ce qui doit être fait, mais n’écrire aucune modification (aussi : --simulate)

-R

Traite récursivement tous les simples fichiers qui correspondent au motif *.deb et qui se trouvent dans les répertoires et sous-répertoires spécifiés (utilisé avec -i ou --unpack

Fichiers

dpkg utilise un certain nombre de fichiers pour son fonctionnement, en commençant par son fichier de configuration /etc/dpkg/dpkg.cfg.

La liste des paquets avec leurs statuts est tenue dans les fichiers /var/lib/dpkg/available et /var/lib/dpkg/status.

Un fichier .deb, en plus des fichiers qui forment le paquet (programmes, bibliothèques, fichiers de configuration), inclue également un certain nombre de fichiers de contrôle. Ces fichiers permettent l'exécution de scripts avant et après l'installation ou la suppression du paquet, ainsi que les listes des fichiers et des fichiers de configuration. Une fois le paquet installé, ces fichiers sont placés dans /var/lib/dpkg/info.

Utilisation de dpkg

Pour installer un paquet à partir d'un fichier .deb, vous pouvez utiliser dpkg comme suit :

dpkg –i hello_2.1.1-4_i386.deb 

OU

dpkg --unpack  hello_2.1.1-4_i386.deb
dpkg --configure hello

Pour supprimer le paquet hello ainsi que sa configuration :

dpkg –P hello

Tandis que la commande suivante supprime le paquet en laissant les fichiers de configuration :

dpkg –r hello

Pour obtenir la liste des paquets installés sur le systéme :

dpkg –l

(!) Lorsque vous travaillez avec un fichier .deb, vous devez donner le nom du fichier, mais lorsque vous travaillez sur des paquets installés, vous ne donnez que le nom du paquet.

APT

La commande dpkg est adaptée pour l'installation de paquets individuels sans dépendances, mais lorsqu'il s'agit d'installer un certain nombre de paquets qui risquent d'avoir des dépendances, on préfère la suite de commandes APT.

APT est l'une des forces de dpkg. C'est un moyen simple pour installer et mettre à jour un système. APT utilise deux fichiers de configuration principaux :

Fichier

Description

/etc/apt/apt.conf

Options de configuration pour APT, comme la version de Debian installée, les paramètres du serveur mandataire (proxy), etc.

/etc/apt/sources

Sources utilisées pour les paquets : sur cédérom, sur le réseau, etc.

En général, on commence par configurer les sources d'APT, ce qui peut être fait avec :

apt-setup

Cette commande demande à l'utilisateur le mirroir à utiliser, et le teste, ou si vous utilisez des cdroms, la commande suivante :

apt-cdrom

Une fois qu'APT sait où il trouve ses paquets, on utilise deux commandes pour la gestion des paquets : apt-cache et apt-get.

apt-cache

apt-cache est utilisé pour accéder aux informations du cache APT (placées dans /var/cache/apt).

Syntaxe :

apt-cache <action> chaîne

Le tableau suivant présente les actions courantes :

Action

Description

search

Recherche la chaîne dans les descriptions de paquets disponibles, et affiche une description courte des paquets correspondants

show

Affiche la description complète du paquet

apt-get

Tandis qu'apt-cache permet d'accéder aux informations sur les paquets disponibles, apt-get permet de mettre à jour ces informations, la récupération, l'installation et la suppression des paquets, et même de mettre à jour la distribution. Tout comme apt-cache, il faut indiquer à apt-get une action. Le tableau suivant décrit les actions les plus courantes pour apt-get :

Action

Description

update

Met à jour la liste des paquets à partir des sources définies dans /etc/apt/sources.list

install package

Installe le(s) paquet(s) indiqué(s) ainsi que leurs dépendances

upgrade

Met à jour tous les paquets pour lesquels une version plus récente existe

dist-upgrade

Met à jour la distribution (il vaut mieux lire les notes de version avant !)

remove

Supprime le(s) paquet(s) spécifié(s)

Utilisation d'APT

L'une des utilisations d'APT les plus courantes est la mise à jour système (par exemple pour installer les mises à jour de sécurité). On le fait généralement avec ces deux commandes :

apt-get update
apt-get upgrade

Une autre utilisation d'APT est l'installation de paquets, pour laquelle on utilise les commandes suivantes :

apt-get update            #met à jour la liste des paquets

apt-cache search frob      #recherche les paquets relatifs à frob

apt-cache show frobnicate  #affiche les informations sur un paquet en particulier

apt-get install frobnicate #installe le paquet frobnicate  et ses dépendances

La commande alien

La commande alien convertit les paquets Debian en paquets RedHat et vice-versa. Vous pouvez télécharge alien sur http://kitenet.net/programs/ (NdT : aujourd'hui alien est distribué comme paquet sur Debian et autres)

Convertir un paquet Debian en rpm :

alien --to-rpm  paquet.deb

Convertir un rpm en deb :

alien --to-deb paquet.rpm

/!\ (NdT) : tâchez de vous rappeler qu'il faut utiliser alien en tant que root pour qu'il traite correctement les propriétaires et groupes des fichiers.

Résumé et exercices

Questions de révision

Oui ou Non

  1. Lorsqu'on compile un programme à partir des sources, on doit compiler chaque partie du code dans l'ordre avec gcc : _

  2. Le programme make ne peut compiler un programme que s'il est lancé dans un répertoire contenant la Makefile approprié : _

  3. Les paquets contenant des binaires et ceux contenant des sources sont deux types de paquets RPM : _

  4. Il est recommandé de lancer ldconfig lorsqu'on installe des bibliothèques partagées à partir des source : _

  5. La commande ldconfig est utilisée pour mettre à jour le ldcache : _

  6. On peut effectuer des recherches en utilisant un gestionnaire de paquets sur les programmes installés à partir des sources : _

  7. Les outils APT permettent d'installer des paquets et des résoudre les dépendances : _

Voir les réponses

Glossaire

Terme

Description

construction

terme utilisé lorsqu'on compile un projet à partir des sources, en général en tapant make

compiler

traduire les instructions écrites dans un langage de haut-niveau en code machine. La sortie de la compilation est appelée le code objet

bibliothèque dynamique

bibliothèque qui peut être chargée pendant l'exécution du programme

bibliothèque partagée

bibliothèque prévue pour être utilisée par plus d'un programme. Les bibliothèques partagées sont généralement dynamiques et portent l'extension .so (pour shared object)

bibliothèque statique

bibliothèque copiée dans l'exécutable au moment de la compilation. Les bibliothèques statiques portent l'extension .a (archive)

langage de haut niveau

langage de programmation lisible par les êtres humains et utilisé pour écrire du code source

éditeur de liens

1. programme utilisé pendant la compilation pour assembler les objets générés par le compilateur en un exécutable - voir ld(1)

1. programme qui charge dynamiquement les bibliothèques partagées nécessaires au lancement des programmes - voir ld.so(8)

code objet

code produit par la compilation. Le code objet peut être soit un exécutable, soit il peut être lié à d'autre code objet pour former un exécutable

tarball

archive tar compressée

Fichiers

Fichier

Description

/etc/ld.so.conf

fichier de configuration de ldconfig

Makefile

fichier lu par make à la construction d'un programme

/etc/rpmrc

utilisé par rpm et rpmbuild (voir LPI 201), ce fichier contient des informations telles que l'architecture système et le chemin pour accéder aux macros et les utilitaires utilisés pour la gestion des paquets. Ce fichier se trouve en général dans le répertoire /usr/lib/rpm/

/usr/lib/rpm/

répertoire contenant les macros utilisées pour la gestion des paquets

/var/lib/rpm/

répertoire contenant les bases de données pour le gestionnaire de paquets (RPM)

Commandes

Commande

Description (apropos)

alien

alien(1) - Convertir ou installer un paquetage binaire d'une autre distribution. alien permet la conversion entre les formats de paquets RedHat (rpm), Debian (deb), Stampede (slp), Slackware (tgz) et Solatis (pkg). Si vous souhaitez utiliser un paquet provenant d'une autre distribution Linux que celle que vous avez installé, vous pouvez utiliser alien pour le convertir au format désiré et l'installer

les outils APT

Suite de commandes permettant d'effectuer des opérations avancées sur des paquets Debian situés sur cédérom ou serveur

configure

script généralement inclut dans les sources d'un projet pour générer le Makefile. Ce script tente de déterminer le type d'architecture, et les autres composants nécessaires à la construction du projet (compilateur, fichiers d'entête, ou bibliothèques)

dpkg

commande utilisée pour manipuler les paquets au format Debian

LD_LIBRARY_PATH

variable d'environnement utilisée par l'éditeur de liens (ld.so) contenant le chemin vers des bibliothèques partagées

ldconfig

programme qui génère le "ldcache" utilisé par l'éditeur de liens pour trouver les bibliothèques partagées. L'option -p permet d'afficher le contenu du cache

ldd

ldd(1) - Affiche les bibliothèques partagées nécessaires

make

info make - La commande make détermine les parties d'un gros programme à recompiler et lance les commandes pour les recompiler

rpm

commande utilisée pour manipuler les paquets au format RPM

Travaux pratiques

Dans l'exemple suivant, téléchargez un paquet RPM source (bash-2.05-8.src.rpm pour RedHat 7.2) à partir de www.rpmfind.net. (NdT : mettez à jour en fonction de la distribution RPM que vous utilisez)

  1. Installation à partir de l'archive tar
    • Installez le contenu du paquet RPM sans compiler quoi que ce soit :
      rpm –ivh bash-2.05-8.src.rpm
    • dans le répertoire /usr/src/redhat/SOURCES, décompressez l'archive avec :

      tar xvzf bash-2.05-8.tar.gz   
    • Facultatif (mais recommandé) : appliquez les correctifs (patchs). La syntaxe dépend du répertoire où vous vous trouvez.

      de /usr/src/redhat/SOURCES :

      patch –p0 –b < fichier.patch

      de /usr/src/redhat/SOURCES/bash-2.05-8

      patch –p1 –b < fichier.patch
    • nous faisons le choix d'installer les fichiers dans un répertoire temporaire, par exemple /tmp/test. Dans un environnement de production, nous placerions les fichiers dans /usr/local. Créons le répertoire :

      mkdir /tmp/test 
    • Enfin, compilons en suivant les étapes habituelles :
      ./configure –prefix=/tmp/test
      make
      make install

      Vous pouvez lister le contenu de /tmp/test/

  2. Pour aller plus loin, nous allons reconstruire un paquet RPM binaire (non nécessaire pour l'examen LPI101)
    • rpm –-rebuild  paquet.src.rpm

      Le paquet créé devrait être dans /usr/src/redhat/RPMS

      • Vérifiez le contenu du paquet avec les options -qpl

      • installer le ou les paquets et lancez des requêtes sur le(s) paquet(s) installé(s)
      • désinstaller le(s) paquet(s)
  3. Configurez /etc/apt/sources avec apt-setup. Utilisez les commandes APT et dpkg pour lancer des requêtes, installer et mettre à jour les paquets disponibles.

Réponses aux questions

  1. non : on utilise make

  2. oui : le Makefile est unique pour chaque projet. la commande make ne peut lire le Makefile qu'à partir du répertoire actuel, c'est à dire le répertoire à partir duquel la commande est lancée.

  3. oui

  4. oui

  5. oui

  6. non

  7. oui

Page consultée 479 fois