JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Guide du développeur de l'empaquetage d'applications     Oracle Solaris 10 1/13 Information Library (Français)
search filter icon
search icon

Informations document

Préface

1.  Conception d'un package

2.  Création d'un package

3.  Amélioration de la fonctionnalité d'un package (opérations)

4.  Vérification et transfert d'un package

5.  Création d'un package : Etudes de cas

6.  Techniques avancées de création de packages

Spécification du répertoire de base

Fichier de valeurs d'administration par défaut

S'habituer à l'incertitude

Utilisation du paramètre BASEDIR

Utilisation des répertoires de base paramétriques

Exemples : Utilisation des répertoires de base paramétriques

Fichier pkginfo

Fichier pkgmap

Gestion du répertoire de base

Prise en compte du réadressage

Parcours des répertoires de base

Utilisation du paramètre BASEDIR

Fichier pkginfo

Fichier pkgmap

Exemple : Analyse de scripts parcourant un BASEDIR

Script request

Script checkinstall

Utilisation de chemins paramétriques relatifs

Fichier pkginfo

Fichier pkgmap

Exemple : Script request parcourant un chemin paramétrique relatif

Prise en charge du réadressage dans un environnement hétérogène

Approche traditionnelle

Packages réadressables

Exemple : Package réadressable traditionnel

Fichier pkginfo

Fichier pkgmap

Packages absolus

Exemple : Package absolu traditionnel

Fichier pkgmap

Packages composites

Exemple : Solution traditionnelle

Fichier pkginfo

Fichier pkgmap

Au-delà de la tradition

Informations supplémentaires sur les packages composites

Noms de chemins absolus à l'apparence réadressable

Exemple : Modification d'un fichier

Description

Implémentation

Exemple

Exemple : Création d'un fichier

Description

Implémentation

Exemple

Exemple : Package composite

Fichier pkginfo

Fichier pkgmap

Création de packages pouvant être installés à distance

Exemple : Installation sur un système client

Exemple : Installation sur un serveur ou un système autonome

Exemple : Montage de systèmes de fichiers partagés

Application de patchs à des packages

Script checkinstall

Script preinstall

Script d'action de classe

Script postinstall

Script patch_checkinstall

Script patch_postinstall

Mise à niveau des packages

Script request

Script postinstall

Création de packages d'archives de classe

Structure du répertoire d'un package d'archive

Mots clés de prise en charge des packages d'archive de classe

Utilitaire faspac

Glossaire

Index

Spécification du répertoire de base

Plusieurs méthodes sont disponibles pour spécifier l'emplacement de l'installation d'un package et il est important de pouvoir modifier le répertoire de base de l'installation dynamiquement lors de la phase d'installation. Lorsque cette spécification est effectuée correctement, un administrateur peut installer plusieurs versions et plusieurs architectures sans difficulté.

Cette section aborde les méthodes courantes avant de passer à des démarches permettant d'améliorer les installations sur des systèmes hétérogènes.

Fichier de valeurs d'administration par défaut

Les administrateurs chargés de l'installation des packages peuvent se servir des fichiers d'administration pour contrôler l'installation des packages. Toutefois, en tant que concepteur de package, vous devez savoir ce qu'est un fichier d'administration et de quelle manière un administrateur peut modifier l'installation prévue d'un package.

Un fichier d'administration indique à la commande pkgadd si elle doit ou non effectuer les contrôles et afficher les invites qu'elle effectue/affiche habituellement. Les administrateurs doivent pour cette raison maîtriser la procédure d'installation d'un package et les scripts qui lui sont associés avant de se servir des fichiers d'administration.

Le système d'exploitation SunOS est livré avec un fichier de valeurs d'administration par défaut que vous trouverez dans /var/sadm/install/admin/default. Il s'agit du fichier établissant le niveau de politique d'administration le plus basique en matière d'installation de produits logiciels. Le fichier tel qu'il est livré est comme suit :

#ident "@(#)default
1.4 92/12/23 SMI"    /* SVr4.0 1.5.2.1    */ 
mail=
instance=unique
partial=ask
runlevel=ask
idepend=ask
rdepend=ask
space=ask
setuid=ask
conflict=ask
action=ask
basedir=default

L'administrateur peut modifier ce fichier afin d'établir de nouveaux comportements par défaut ou, créer un autre fichier d'administration et spécifier son existence à l'aide de l'option -a dans la commande pkgadd.

Onze paramètres peuvent être définis dans un fichier d'administration ; toutefois, certains sont facultatifs. Pour plus d'informations, reportez-vous à admin(4).

Le paramètre basedir spécifie la manière dont le répertoire de base est généré à l'installation d'un package. La plupart des administrateurs conservent la valeur default mais le paramètre basedir peut prendre une des valeurs suivantes :


Remarque - Si la commande pkgadd est appelée avec l'argument - a none, elle demande systématiquement le répertoire de base à l'administrateur. Malheureusement, cette commande définit également tous les paramètres du fichier sur la valeur par défaut quit qui est susceptible d'engendrer des problèmes supplémentaires.


S'habituer à l'incertitude

Un administrateur contrôle tous les packages installés sur un système via l'utilisation d'un fichier d'administration. Un autre fichier de valeurs d'administration par défaut est malheureusement souvent fourni par le concepteur du package ; ce fichier ignore en effet les souhaits de l'administrateur.

Les concepteurs de package incluent parfois un autre fichier d'administration qui leur permet (et non pas à l'administrateur) de contrôler l'installation d'un package. Etant donné que l'entrée basedir du fichier de valeurs d'administration par défaut ignore tous les autres répertoires de base, elle représente une méthode simple de sélection du répertoire de base lors de la phase d'installation. Dans toutes les versions du SE Oracle Solaris antérieures à 2.5, cette méthode était considérée comme la plus simple pour contrôler le répertoire de base.

Toutefois, vous devez tenir compte des souhaits de l'administrateur relatifs à l'installation du produit. La présence d'un fichier temporaire de valeurs d'administration par défaut destiné à contrôler l'installation induit la méfiance chez les administrateurs. Utilisez un script request et un script checkinstall pour contrôler ces installations sous la direction de l'administrateur. Si le script request implique véritablement l'administrateur dans la procédure, l'empaquetage du System V bénéficiera à la fois aux administrateurs et aux concepteurs de package.

Utilisation du paramètre BASEDIR

Le fichier pkginfo de tout package réadressable doit contenir une entrée spécifiant le répertoire de base par défaut dans le format suivant :

BASEDIR=absolute_path

Il ne s'agit que du répertoire de base par défaut et peut de ce fait être remplacé par l'administrateur au cours de l'installation.

Bien que certains packages requièrent plusieurs répertoires de base, l'avantage que présente ce paramètre pour le placement du package est que le répertoire de base est déjà créé et prêt à être utilisé dès le lancement de l'installation. Le chemin d'accès approprié au répertoire de base du serveur et du client est mis à la disposition de tous les scripts de procédure sous la forme de variables d'environnement réservées. La commande pkginfo -r SUNWstuf affiche la base d'installation actuelle du package.

Dans le script checkinstall, BASEDIR est le paramètre tel qu'il a été défini dans le fichier pkginfo (non encore déterminé). Afin de vérifier le répertoire de base cible, la construction ${PKG_INSTALL_ROOT}$BASEDIR est nécessaire. Ceci signifie que le script request ou checkinstall peut remplacer la valeur de BASEDIR dans l'environnement d'installation avec des résultats prévisibles. Le temps que le script preinstall soit appelé, le paramètre BASEDIR a été remplacé par le pointeur entièrement conditionné du répertoire de base actuel sur le système cible, même si le système est un client.


Remarque - Le script request se sert du paramètre BASEDIR différemment selon la version du système d'exploitation SunOS. Afin de tester un paramètre BASEDIR dans un script request, le code suivant doit être utilisé pour déterminer le répertoire de base alors utilisé.

# request script
constructs base directory
if [ ${CLIENT_BASEDIR} ]; then
      LOCAL_BASE=$BASEDIR
else
      LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR
fi

Utilisation des répertoires de base paramétriques

Si un package nécessite plusieurs répertoires de base, vous pouvez les créer à l'aide de noms de chemin paramétriques. Cette méthode est devenue assez populaire bien qu'elle présente les inconvénients suivants :

Bien que les paramètres qui déterminent les répertoires de base soient définis dans le fichier pkginfo, ils peuvent être modifiés par le script request. Cette caractéristique est une des raisons principales de la popularité de cette approche. Les inconvénients sont cependant chroniques et il est recommandé de n'utiliser cette configuration qu'en dernier ressort.

Exemples : Utilisation des répertoires de base paramétriques

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=/
EZDIR=/usr/stuf/EZstuf
HRDDIR=/opt/SUNWstuf/HRDstuf
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none
PSTAMP=hubert980707141632
Fichier pkgmap
: 1 1758
1 d none $EZDIR 0775 root bin
1 f none $EZDIR/dirdel 0555 bin bin 40 773 751310229
1 f none $EZDIR/usrdel 0555 bin bin 40 773 751310229
1 f none $EZDIR/filedel 0555 bin bin 40 773 751310229
1 d none $HRDDIR 0775 root bin
1 f none $HRDDIR/mksmart 0555 bin bin 40 773 751310229
1 f none $HRDDIR/mktall 0555 bin bin 40 773 751310229
1 f none $HRDDIR/mkcute 0555 bin bin 40 773 751310229
1 f none $HRDDIR/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

Gestion du répertoire de base

Tout package disponible en plusieurs versions ou destiné à plusieurs architectures doit être conçu de sorte à pouvoir, le cas échéant, parcourir le répertoire de base. Le parcours d'un répertoire de base signifie que si une version précédente ou une architecture différente du package sur le point d'être installée se trouve déjà dans le répertoire de base, ce package résout le problème, en créant par exemple un nouveau répertoire de base sous un nom légèrement différent. Les scripts request et checkinstall de Solaris 2.5 et des versions compatibles sont en mesure de modifier la variable d'environnement BASEDIR. Ceci n'est pas le cas des versions précédentes du système d'exploitation Oracle Solaris.

Même dans les versions plus anciennes du système d'exploitation Oracle Solaris, le script request pouvait redéfinir les répertoires au sein de la base d'installation. Le script request est en mesure d'effectuer cette opération d'une manière prenant en charge la plupart des préférences d'administration.