Demande de participation de l'administrateur

Le package décrit dans cette étude de cas contient trois types d'objets. L'administrateur peut sélectionner le type d'objets qu'il souhaite installer et l'emplacement des objets sur la machine d'installation.

Techniques

Cette étude de cas illustre les techniques suivantes :

• Utilisation de noms de chemin paramétriques (variables contenues dans les noms de chemin d'objet utilisées pour définir plusieurs répertoires de base)

  Pour plus d'informations sur les noms de chemin paramétriques, reportez-vous à Noms de chemin paramétriques.

• Utilisation d'un script request pour demander la participation de l'administrateur

  Pour plus d'informations sur les scripts request, reportez-vous à Rédaction d'un script request.

• Définition de valeurs conditionnelles pour un paramètre d'installation.

Démarche

Pour définir l'installation sélective de cette étude de cas, vous devez effectuer les opérations suivantes :

• Définir une classe pour chaque type d'objet pouvant être installé.

  Dans cette étude de cas, les trois types d'objet sont les fichiers exécutables du package, les pages de manuel et les exécutablesemacs. Chaque type dispose de sa propre classe : respectivement bin, man et emacs. Notez que dans le fichier prototype, tous les fichiers d'objets appartiennent à une de ces trois classes.

• Donner au paramètre CLASSES du fichier pkginfo la valeur nulle.

  En règle générale lorsque vous définissez une classe, vous devez indiquer cette classe dans le paramètre CLASSES du fichier pkginfo. Aucun objet de cette classe ne peut sinon être installé. Dans cette étude de cas, la valeur de ce paramètre est au départ nulle, signifiant qu'aucun objet ne peut être installé. Le paramètre CLASSES est ensuite remplacé via le script request, en fonction des choix de l'administrateur. De cette façon, le paramètre CLASSES ne contient que la valeur des types d'objet que l'administrateur souhaite installer.

  ---

  Remarque - Il est recommandé de donner aux paramètres une valeur par défaut. Si le package contient par exemple des composants communs aux trois types d'objet, vous pouvez les attribuer à la classe none et donner au paramètre CLASSES la valeur none.

  ---

• Insérer les noms de chemin paramétriques dans le fichier prototype.

  Le script request donne à ces variables d'environnement la valeur fournie par l'administrateur. La commande pkgadd résout ensuite ces variables d'environnement lors de la phase d'installation pour connaître l'emplacement de l'installation du package.

  Les trois variables d'environnement utilisées dans cet exemple sont définies sur leur valeur par défaut dans le fichier pkginfo et ont les rôles suivants :

  • $NCMPBIN définit l'emplacement des exécutables des objets ;

  • $NCMPMAN définit l'emplacement des pages de manuel ;

  • $EMACS définit l'emplacement des exécutables emacs.

  L'exemple de fichier prototype illustre la manière de définir les noms de chemin des objets avec des variables.

• Créer un script request pour demander à l'administrateur quelles parties du package doivent être installées et à quel endroit les placer.

  Le script request de ce package pose deux questions à l'administrateur :

  • Cette partie du package doit-elle être installée ?

    Lorsque la réponse est oui, le nom de classe approprié est ajouté au paramètre CLASSES. Par exemple, lorsque l'administrateur choisit d'installer les pages de manuel associées au package, la classe man est ajoutée au paramètre CLASSES.

  • Dans ce cas, à quel endroit cette partie du package doit-elle être placée ?

    La variable d'environnement appropriée est définie sur la réponse à cette question. Dans l'exemple des pages de manuel, la variable $NCMPMAN prend la valeur donnée en réponse.

  Ce deux questions sont réitérées pour chacun de trois types d'objet.

  A la fin du script request, les paramètres sont mis à la disposition de l'environnement d'installation pour la commande pkgadd et tout autre script d'empaquetage. Le script request effectue cette opération en enregistrant ces définitions dans le fichier fourni par l'utilitaire d'appel. Aucun autre script n'est fourni pour cette étude de cas.

  Remarquez dans ce script request que les questions sont générées par les outils de validation des données ckyorn et ckpath. Pour plus d'informations sur ces outils, reportez-vous à ckyorn(1) et ckpath(1).

Fichiers de l'étude de cas

Fichier pkginfo

PKG=ncmp
NAME=NCMP Utilities
CATEGORY=application, tools
BASEDIR=/
ARCH=SPARC
VERSION=RELEASE 1.0, Issue 1.0
CLASSES=""
NCMPBIN=/bin
NCMPMAN=/usr/man
EMACS=/usr/emacs

Fichier prototype

i pkginfo
i request
x bin $NCMPBIN 0755 root other
f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other
f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other
f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other
f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other
x emacs $EMACS 0755 root other
f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other
f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other
f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other
f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other
f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other
f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other
d man $NCMPMAN 0755 root other
d man $NCMPMAN/man1 0755 root other
f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other
f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other
f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other

Script request

trap 'exit 3' 15
# determine if and where general executables should be placed
ans=`ckyorn -d y \
-p "Should executables included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES bin"
   NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \
   -p "Where should executables be installed"
   ` || exit $?
fi
# determine if emacs editor should be installed, and if it should
# where should the associated macros be placed
ans=`ckyorn -d y \
-p "Should emacs editor included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES emacs"
   EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \
   -p "Where should emacs macros be installed"
   ` || exit $?
fi

Remarquez qu'un script request peut s'arrêter sans ne laisser aucun fichier dans le système de fichiers. Dans le cadre des installations sur les versions antérieures à 2.5 d'Oracle Solaris et versions compatibles (où aucun script checkinstall ne peut être utilisé), le script request est l'endroit où effectuer tous les tests nécessaires vis à vis du système de fichiers afin de garantir le succès de l'installation. Lorsque le script request contient le code 1, l'installation s'arrête nette.

Ces exemples de fichiers illustrent l'emploi des chemins paramétriques pour définir plusieurs répertoires de base. Toutefois, la méthode recommandée implique l'utilisation du paramètre BASEDIR qui est géré et validé par la commande pkgadd. Chaque fois que plusieurs répertoires de base sont utilisés, prenez les mesures nécessaires en prévision de l'installation de plusieurs versions et architectures sur la même plate-forme.