Approche traditionnelle

Packages réadressables

L'ABI du System V suggère que le premier objectif d'un package réadressable était de simplifier l'installation du package pour l'administrateur. De nos jours, la nécessité des packages réadressables va plus loin. Il n'est plus seulement question de commodité puisqu'il arrive souvent lors de l'installation qu'un produit logiciel actif se trouve déjà dans le répertoire par défaut. Un package non conçu dans l'optique de gérer cette situation peut soit remplacer le produit existant, soit suspendre l'installation. Par contre, un package conçu pour gérer plusieurs architectures et plusieurs versions peut procéder à l'installation correctement et offrir à l'administrateur diverses options entièrement compatibles avec les habitudes d'administration déjà en place.

D'une certaine manière, le problème lié à l'existence de plusieurs architectures et celui lié à plusieurs versions est le même. Il faut pouvoir installer une variante du package actuel parallèlement à d'autres variantes et pouvoir diriger les clients ou les utilisateurs de systèmes autonomes de fichiers exportés vers n'importe laquelle de ces variantes sans y perdre en fonctionnalité. Bien que Sun ait établi des méthodes permettant de gérer plusieurs architectures sur un serveur, les administrateurs ne se conforment pas toujours à ces recommandations. Tous les packages doivent pouvoir se conformer aux souhaits raisonnables des administrateurs en matière d'installation.

Exemple : Package réadressable traditionnel

L'exemple suivant illustre l'apparence d'un package réadressable traditionnel. Le package doit être placé dans /opt/SUNWstuf et ses fichiers pkginfo et pkgmap peuvent s'afficher comme suit :

Fichier pkginfo

# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert990707141632

Fichier pkgmap

: 1 1758
1 d none SUNWstuf 0775 root bin
1 d none SUNWstuf/EZstuf 0775 root bin
1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none SUNWstuf/HRDstuf 0775 root bin
1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

On parle ici de méthode traditionnelle car chaque objet de package est installé dans le répertoire de base défini par le paramètre BASEDIR du fichier pkginfo. Par exemple, le premier objet du fichier pkgmap est installé comme répertoire /opt/SUNWstuf.

Packages absolus

Un package absolu est un package qui s'installe sur un système de fichiers root (/) particulier. Ces packages sont difficiles à gérer du point de vue de plusieurs versions et architectures. En règle générale, tous les packages doivent être réadressables. Il existe cependant de très bonnes raisons d'inclure des éléments absolus dans un package réadressable.

Exemple : Package absolu traditionnel

Si le package SUNWstuf était un package absolu, le paramètre BASEDIR ne devrait pas être défini dans le fichier pkginfo et le fichier pkgmap serait comme suit :

Fichier pkgmap

: 1 1758
1 d none /opt ? ? ?
1 d none /opt/SUNWstuf 0775 root bin
1 d none /opt/SUNWstuf/EZstuf 0775 root bin
1 f none /opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none /opt/SUNWstuf/HRDstuf 0775 root bin
1 f none /opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none /opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

Dans cet exemple, si l'administrateur a spécifié un autre répertoire de base lors de l'installation, il est ignoré par la commande pkgadd. Ce package s'installe toujours dans /opt/SUNWstuf du système cible.

L'argument -R de la commande pkgadd fonctionne comme prévu. Par exemple,

pkgadd -d . -R /export/opt/client3 SUNWstuf

installe les objets dans /export/opt/client3/opt/SUNWstuf ; toutefois, il s'agit du seul semblant de réadressage de ce package.

Notez l'emploi du point d'interrogation (?) pour le répertoire /opt du fichier pkgmap. Il indique que les attributs actuels ne doivent pas être modifiés. Cela ne signifie pas « créer le répertoire à partir des attributs par défaut », bien que cela puisse se produire dans certaines situations. Tout répertoire spécifique au nouveau package doit spécifier tous les attributs de manière explicite.

Packages composites

Tout package contenant des objets réadressables est appelé un package réadressable. Ceci peut porter à confusion puisque le fichier pkgmap du package réadressable peut contenir des chemins absolus. L'utilisation d'une entrée racine (/) dans un fichier pkgmap peut améliorer les aspects réadressables du package. Les packages contenant à la fois des entrées réadressables et des entrées racines sont appelés des packages composites.

Exemple : Solution traditionnelle

Supposons qu'un objet dans le package SUNWstuf soit un script de démarrage exécuté au niveau d'exécution 2. Vous devez installer le fichier /etc/rc2.d/S70dostuf en tant que partie du package mais vous ne pouvez pas le placer dans le répertoire de base. Supposons qu'un package réadressable soit l'unique solution ; les fichiers pkginfo et pkgmap seraient comme suit :

Fichier pkginfo

# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert990707141632

Fichier pkgmap

: 1 1758
1 d none opt/SUNWstuf/EZstuf 0775 root bin
1 f none opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none opt/SUNWstuf/HRDstuf 0775 root bin
1 f none opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none etc	? ? ?
1 d none etc/rc2.d ? ? ?
1 f none etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865

Il n'existe pas de grandes différences entre cette approche et celle utilisée pour le package absolu. Un package absolu est en fait plus approprié car si l'administrateur a spécifié un autre répertoire de base, cette solution ne fonctionne pas.

En fait, seul un fichier de ce package doit être relatif à la racine ; les autres peuvent être placés n'importe où. L'utilisation d'un package composite comme solution à ce problème est abordée dans la suite de cette section.