test

Guide du développeur pour l'empaquetage d'applications

Création de scripts d'installation

Cette section décrit les scripts d'installation de package facultatifs. La commande pkgadd effectue automatiquement toutes les opérations nécessaires pour installer un package à l'aide de fichiers d'information de package comme entrée. Il n'est pas nécessaire de fournir des scripts d'installation de package. Toutefois, pour créer des procédures d'installation personnalisées pour votre package, vous pouvez faire appel à des scripts d'installation. Scripts d'installation :

Il existe quatre types de scripts d'installation vous permettant d'effectuer des opérations personnalisées :

Traitement des scripts pendant l'installation d'un package

Le type de scripts à utiliser dépend du stade de la procédure d'installation auquel l'action du script est requise. Pendant l'installation d'un package, la commande pkgadd effectue les opérations suivantes :

  1. Elle exécute le script request.

    Cette opération est la seule au cours de laquelle votre package peut demander la participation de l'administrateur chargé d'installer le package .

  2. Elle exécute le script checkinstall.

    Le script checkinstall recueille les données du système de fichiers et peut créer ou modifier la définition des variables d'environnement afin de contrôler l'installation ultérieure. Pour plus d'informations sur les variables d'environnement d'un package, reportez-vous à Variables d'environnement d'un package.

  3. Elle exécute le script preinstall.

  4. Elle installe les objets de package de chaque classe à installer.

    L'installation de ces fichiers s'effectue classe par classe et les scripts d'action de classe sont exécutés en conséquence. La liste des classes employées et l'ordre dans lequel elles doivent être installées sont initialement définis avec le paramètre CLASSES dans votre fichier pkginfo. Toutefois, votre script request ou checkinstall peut modifier la valeur du paramètre CLASSES. Pour plus d'informations sur le traitement des classes pendant l'installation, reportez-vous à Traitement des classes pendant l'installation d'un package.

    1. Crée des liens symboliques, des périphériques, des tubes nommés et les répertoires requis.

    2. Installe les fichiers standard (fichiers de type e, v, f), en fonction de leur classe.

      Seuls les fichiers standard à installer sont transmis au script d'action de classe. Tous les autres objets de package sont créés automatiquement à partir des informations figurant dans le fichier pkgmap.

    3. Crée tous les liens physiques.

  5. Elle exécute le script postinstall.

Traitement des scripts pendant la suppression d'un package

Lors de la suppression d'un package, la commande pkgrm effectue les opérations suivantes :

  1. Elle exécute le script preremove.

  2. Elle supprime les objets de package de chaque classe.

    La suppression s'effectue également classe par classe. Les scripts de suppression sont traités dans l'ordre inverse de l'installation, en fonction de la séquence définie dans le paramètre CLASSES. Pour plus d'informations sur le traitement des classes pendant l'installation, reportez-vous à Traitement des classes pendant l'installation d'un package.

    1. Supprime les liens physiques.

    2. Supprime les fichiers standard.

    3. Supprime les liens symboliques, les périphériques et les tubes nommés.

  3. Elle exécute le script postremove.

Le script request n'est pas traité lors de la suppression d'un package. Toutefois, le résultat du script est conservé dans le package installé et mis à la disposition des scripts de suppression. Le résultat du script request est une liste de variables d'environnement.

Variables d'environnement de package mises à la disposition des scripts

Les groupes suivants de variables d'environnement sont mis à la disposition de tous les scripts d'installation. Certaines variables d'environnement peuvent être modifiées par un script request ou un script checkinstall.

Obtention d'informations sur un package pour un script

Deux commandes peuvent être utilisées à partir de scripts pour demander des informations sur un package :

Codes de sortie des scripts

Chaque script doit quitter son exécution avec l'un des codes de sortie figurant dans le tableau suivant.

Tableau 3–2 Codes de sortie des scripts d'installation

Code 

Signification 

0 

Script exécuté avec succès.  

1 

Erreur fatale. La procédure d'installation est annulée à ce moment-là.  

2  

Avertissement ou cas d'erreur. L'installation se poursuit. Un message d'avertissement s'affiche en fin de procédure.  

3  

Arrêt net de la commande pkgadd. Seul le script checkinstall renvoie ce code.

10  

Le système doit être réinitialisé à l'issue de l'installation de tous les packages sélectionnés. (Cette valeur doit être ajoutée à l'un des codes de sortie à un seul chiffre.)  

20  

Le système doit être immédiatement réinitialisé à l'issue de l'installation du package actuel. (Cette valeur doit être ajoutée à l'un des codes de sortie à un seul chiffre.)  

Reportez-vous au Chapitre5Création d'un package : Études de cas pour consulter des exemples de codes de sortie renvoyés par les scripts d'installation.

Remarque –

Tous les scripts d'installation fournis avec votre package doivent disposer d'une entrée dans le fichier prototype. Le type de fichier doit être i (script d'installation de package).

Rédaction d'un script request

Le script request est le seul moyen d'interaction directe avec l'administrateur chargé d'installer le package. Ce script peut être utilisé par exemple pour demander à l'administrateur s'il souhaite installer certains des éléments facultatifs du package.

Le résultat du script request doit être une liste de variables d'environnement et de leurs valeurs. Cette liste peut inclure tout paramètre créé dans le fichier pkginfo, ainsi que les paramètres CLASSES et BASEDIR. La liste peut également introduire des variables d'environnement non définies ailleurs. Toutefois et dans la mesure du possible, les valeurs par défaut.le doivent toujours être fournies par le fichier pkginfo . Pour plus d'informations sur les variables d'environnement d'un package, reportez-vous à Variables d'environnement d'un package.

Lorsque votre script request attribue des valeurs à une variable d'environnement, il doit par la suite mettre ces valeurs à la disposition de la commande pkgadd et des autres scripts du package.

Comportements du script request

Règles de conception pour les scripts request

Remarque –

Si les administrateurs chargés d'installer votre package utilisent le produit JumpStartTM, l'installation du package ne doit pas être interactive. Vous pouvez au choix, ne pas fournir de script request avec votre package ou, indiquer aux administrateurs qu'ils doivent utiliser la commande pkgask avant l'installation. La commande pkgask stocke les réponses fournies au script request. Pour plus d'informations sur la commande pkgask, reportez-vous à la page de manuel pkgask(1M).

ProcedureProcédure de rédaction d'un script request

  1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

  2. Créez un fichier nommé request à l'aide de votre éditeur de texte.

  3. Enregistrez vos modifications puis quittez l'éditeur.

  4. Effectuez l'une des opérations suivantes :

  5. Créez votre package.

    Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Exemple 3–5 Rédaction d'un script request

Lorsqu'un script request attribue des valeurs à des variables d'environnement, il doit mettre ces valeurs à la disposition de la commande pkgadd. Cet exemple illustre le segment d'un script request qui effectue cette opération pour les quatre variables d'environnement : CLASSES, NCMPBIN, EMACS et NCMPMAN. Supposons que ces variables ont été définies lors d'une session interactive avec l'administrateur au début du script.


# make environment variables available to installation
# service and any other packaging script we might have
 
cat >$1 <<!
CLASSES=$CLASSES
NCMPBIN=$NCMPBIN
EMACS=$EMACS
NCMPMAN=$NCMPMAN
!
Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vérification et transfert d'un package vous explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un support de distribution.

Recueil de données d'un système de fichiers à l'aide du script checkinstall

Le script checkinstall est exécuté peu de temps après le script request facultatif. Le script checkinstall s'exécute en tant qu'utilisateur install, si celui-ci existe, ou en tant qu'utilisateur nobody. Le script checkinstall ne dispose pas des droits nécessaires pour modifier les données du système de fichiers. Il peut cependant, en fonction des informations qu'il recueille, créer ou modifier des variables d'environnement afin de contrôler la procédure d'installation résultante. Le script est également capable de procéder à un arrêt net de la procédure d'installation.

Le script checkinstall a pour rôle d'effectuer des contrôles de base sur un système de fichiers, contrôles inhabituels pour la commande pkgadd. Ce script peut par exemple être utilisé pour déterminer à l'avance si certains fichiers du package actuel vont écraser des fichiers existants, ou pour gérer les dépendances globales des logiciels. Le fichier depend ne gère que les dépendances au niveau du package.

À l'inverse du script request, le script checkinstall est exécuté qu'un fichier réponse soit fourni ou non. La présence du script ne qualifie pas le package d'interactif. Le script checkinstall peut être des situations où un script request est interdit ou que l'interaction avec l'administrateur n'est pas pratique.

Remarque –

Le script checkinstall est disponible depuis la version 2.5 de Solaris et versions compatibles.

Comportements du script checkinstall

Règles de conception pour les scripts checkinstall

ProcedureProcédure de recueil de données d'un système de fichiers

  1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

  2. Créez un fichier nommé checkinstall à l'aide de votre éditeur de texte.

  3. Enregistrez vos modifications puis quittez l'éditeur.

  4. Effectuez l'une des opérations suivantes :

  5. Créez votre package.

    Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Exemple 3–6 Rédaction d'un script checkinstall

Cet exemple de script checkinstall vérifie que le logiciel de base de données requis par le package SUNWcadap est installé.


# checkinstall script for SUNWcadap
#
# This confirms the existence of the required specU database
 
# First find which database package has been installed.
pkginfo -q SUNWspcdA	# try the older one
 
if [ $? -ne 0 ]; then
   pkginfo -q SUNWspcdB	# now the latest
 
	  if [ $? -ne 0 ]; then	# oops
		    echo "No database package can be found. Please install the"
		    echo "SpecU database package and try this installation again."
		    exit 3		# Suspend
	  else
		    DBBASE="`pkgparam SUNWsbcdB BASEDIR`/db"	# new DB software
	  fi
else
	  DBBASE="`pkgparam SUNWspcdA BASEDIR`/db"	# old DB software
fi
 
# Now look for the database file we will need for this installation
if [ $DBBASE/specUlatte ]; then
	  exit 0		# all OK
else
	  echo "No database file can be found. Please create the database"
	  echo "using your installed specU software and try this"
	  echo "installation again."
	  exit 3		# Suspend
fi
Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vérification et transfert d'un package vous explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un support de distribution.

Rédaction de scripts de procédure

Les scripts de procédure fournissent la liste d'instructions à suivre à certains stades de l'installation ou de la suppression d'un package. Les quatre scripts de procédure doivent porter un des noms prédéfinis liés au stade de l'exécution des instructions. Les scripts sont exécutés sans arguments.

Comportements des scripts de procédure

Les scripts de procédure sont exécutés en tant que uid=root et gid=other.

Règles de conception des scripts de procédure

ProcedureProcédure de rédaction de scripts de procédure

  1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

  2. Créez un ou plusieurs scripts de procédure à l'aide de votre éditeur de texte.

    Un script de procédure doit porter l'un des noms prédéfinis suivants : preinstall, postinstall, preremove ou postremove.

  3. Enregistrez les modifications et quittez l'éditeur.

  4. Effectuez l'une des opérations suivantes :

  5. Créez votre package.

    Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Voir aussi

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vérification et transfert d'un package vous explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un support de distribution.

Rédaction de scripts d'action de classe

Définition de classes d'objets

Les classes d'objets permettent d'effectuer une série d'opérations sur un groupe d'objets de package lors de l'installation ou de la suppression. Vous attribuez des objets à une classe dans le fichier prototype. Une classe doit être attribuée à tous les objets de package, bien que la classe none soit utilisée par défaut pour les objets ne requérant aucune opération particulière.

Le paramètre d'installation CLASSES défini dans le fichier pkginfo correspond à la liste de classes à installer (y compris la classe none).

Remarque –

Les objets définis dans le fichier pkgmap appartenant à une classe non répertoriée dans ce paramètre du fichier pkginfo ne sont pas installés.

La liste CLASSES détermine l'ordre d'installation. La classe none, lorsqu'elle est présente, est toujours installée en premier et supprimée en dernier. Étant donné que les répertoires représentent la structure de prise en charge élémentaire de tous les autres objets d'un système de fichiers, ils doivent tous être attribués à la classe none. Des exceptions peuvent être faites mais en règle générale, la classe none est la plus sûre. Cette stratégie garantit que les répertoires sont créés avant les objets qu'ils contiennent. D'autre part, aucune tentative de suppression d'un répertoire n'est faite avant qu'il n'ait été vidé.

Traitement des classes pendant l'installation d'un package

La section suivante décrit le déroulement des opérations système lors de l'installation d'une classe. Les opérations sont répétées une fois pour chaque volume d'un package à l'installation du volume en question.

  1. La commande pkgadd crée une liste de noms de chemin.

    La commande pkgadd crée une liste de noms de chemin sur lesquels le script d'action opère. Chaque ligne de la liste contient des noms de chemin source et de destination séparés par un espace. Le nom de chemin source indique où l'objet à installer réside sur le volume d'installation. Le nom de chemin de destination indique l'emplacement d'installation de l'objet sur le système cible. Le contenu de la liste est restreint par les critères suivants :

    • La liste ne contient que des noms de chemin appartenant à la classe associée.

    • Si la tentative de création des objets du package échoue, les répertoires, tubes nommés, périphériques en mode caractère, périphériques en mode bloc et liens symboliques sont inclus dans la liste avec comme nom de chemin source, /dev/null. En règle générale, ces éléments sont automatiquement créés par la commande pkgadd (s'ils n'existent pas encore) et il leur est attribué des attributs propres (mode, owner, group) tels qu'ils sont définis dans le fichier pkgmap.

    • Les fichiers liés dont le type est l ne sont en aucun cas inclus dans la liste. Les liens physiques de la classe donnée sont créés à l'étape 4.

  2. Si aucun script d'action de classe n'est fourni pour l'installation d'une classe spécifique, les noms de chemin figurant dans la liste générée sont copiés du volume à l'emplacement cible approprié.

  3. Si un script d'action de classe est présent, il est exécuté.

    Le script d'action de classe est appelé avec l'entrée standard contenant la liste générée à l'étape 1. Si ce volume est le dernier du package ou si cette classe ne contient plus d'objets, le script est exécuté avec le seul argument ENDOFCLASS.

    Remarque –

    Même si aucun fichier standard de cette classe ne figure dans le package, le script d'action de classe est appelé au moins une fois avec une liste vide et l'argument ENDOFCLASS.

  4. La commande pkgadd réalise un audit du contenu et des attributs, et crée des liens physiques.

    Une fois l'étape 2 ou l'étape 3 exécutée avec succès, la commande pkgadd vérifie les informations du contenu et des attributs de la liste des noms de chemin. La commande pkgadd crée automatiquement les liens associés à la classe. Toute incohérence d'attributs des noms de chemin est corrigée dans la liste générée.

Traitement des classes pendant la suppression d'un package

Les objets sont supprimés d'une classe après l'autre. Les classes existant pour un package mais non répertoriées dans le paramètre CLASSES sont supprimées en premier (par exemple, un objet installé à l'aide de la commande installf). Les classes répertoriées dans le paramètre CLASSES sont supprimées dans l'ordre inverse. La classe none est toujours supprimée en dernier. La section suivante décrit le déroulement des opérations système lors de la suppression d'une classe :

  1. La commande pkgrm crée une liste de noms de chemin.

    La commande pkgrm crée une liste des noms de chemin installés appartenant à la classe indiquée. Les noms de chemin auxquels un autre package fait référence sont exclus de la liste à moins que leur type de fichier ne soit e. Le type de fichier e signifie que le fichier doit être modifié lors de l'installation ou de la suppression.

    Si le package à supprimer a modifié des fichiers de type e lors de l'installation, il ne doit supprimer que les lignes qu'il a ajoutées. Ne supprimez pas un fichier modifiable non vide. Supprimez les lignes ajoutées par le package.

  2. Si aucun script d'action de classe n'est présent, les noms de chemin sont supprimés.

    Si votre package ne contient aucun script d'action de classe de suppression pour la classe, tous les noms de chemin figurant dans la liste générée par la commande pkgrm sont supprimés.

    Remarque –

    Les fichiers de type e (modifiables) ne sont pas attribués à une classe ni à un script d'action de classe associé. Ces fichiers sont à ce stade supprimés, même si le nom de chemin est partagé avec d'autres packages.

  3. Si un script d'action de classe est présent, il est exécuté.

    La commande pkgrm appelle le script d'action de classe avec une entrée standard pour le script contenant la liste générée à l'étape 1.

  4. La commande pkgrm réalise un audit.

    Après avoir exécuté le script d'action de classe, la commande pkgrm supprime les références aux noms de chemin figurant dans la base de données du package, à l'exception de celles auxquelles un autre package fait référence.

Script d'action de classe

Ce script d'action de classe définit un groupe d'opérations à exécuter pendant l'installation ou la suppression d'un package. Les opérations sont effectuées sur un un groupe de noms de chemin d'après leur définition de classe. Reportez-vous au Chapitre5Création d'un package : Études de cas pour consulter des exemples de scripts d'action de classe.

Le nom d'un script d'action de classe est basé sur la classe à laquelle il s'applique et la phase durant laquelle les opérations ont lieu, à savoir pendant l'installation ou la suppression du package. Les deux formats de nom sont indiqués dans le tableau suivant :

Format du nom 

Description 

i.classe

Opère sur des noms de chemin de la classe indiquée pendant l'installation du package. 

r.classe

Opère sur des noms de chemin de la classe indiquée pendant la suppression du package.  

Par exemple, le nom du script d'installation d'une classe nommée manpage est i.pmanpage. Le script de suppression est nommé r.manpage.

Remarque –

Ce format de nom de fichier n'est pas utilisé pour les fichiers appartenant aux classes système sed, awk ou build. Pour plus d'informations sur ces classes spéciales, reportez-vous à Classes système spéciales.

Comportements des scripts d'action de classe

Règles de conception des scripts d'action de classe

Classes système spéciales

Le système fournit quatre classes spéciales :

Si plusieurs fichiers d'un package nécessitent un traitement spécial pouvant être intégralement défini par les commandes sed, awk ou sh, l'installation est plus rapide avec les classes système qu'avec plusieurs classes et les scripts d'action de classe qui leur sont associés.

Script de classe sed

La classe sed offre un moyen de modifier un objet existant sur le système cible. Le script d'action de classe sed s'exécute automatiquement à l'installation en présence d'un fichier appartenant à la classe sed. Le nom du script d'action de classe sed doit être identique au nom du fichier sur lequel les instructions sont exécutées.

Un script d'action de classe sed fournit des instructions sed au format suivant :

Deux commandes indiquent à quel moment les instructions doivent être exécutées. Les instructions sed qui suivent la commande !install sont exécutées pendant l'installation du package. Les instructions sed qui suivent la commande !remove sont exécutées pendant la suppression du package. L'ordre dans lequel les commandes sont utilisées dans le fichier n'est pas important.

Pour plus d'informations sur les instructions sed, reportez-vous à la page de manuel sed(1) Pour consulter des exemples de scripts d'action de classe sed, reportez-vous au Chapitre5Création d'un package : Études de cas.

Script de classe awk

La classe awk offre un moyen de modifier un objet existant sur le système cible. Les modifications sont fournies sous forme d'instructions awk dans un script d'action de classe awk.

Le script d'action de classe awk s'exécute automatiquement à l'installation en présence d'un fichier appartenant à la classe awk. Un tel fichier contient des instructions pour un script de classe awk au format suivant :

Deux commandes indiquent à quel moment les instructions doivent être exécutées. Les instructions awk qui suivent la commande !install sont exécutées pendant l'installation du package. Les instructions qui suivent la commande !remove sont exécutées pendant la suppression du package. Ces commandes peuvent être utilisées dans un ordre quelconque.

Le nom du script d'action de classe awk doit être identique au nom du fichier sur lequel les instructions sont exécutées.

Le fichier à modifier est utilisé comme entrée de la commande awk et le résultat du script remplace en fin de compte l'objet d'origine. Aucune variable d'environnement ne peut être transmise à la commande awk avec cette syntaxe.

Pour plus d'informations sur les instructions awk, reportez-vous à la page de manuel awk(1).

Script de classe build

La classe build crée ou modifie un fichier d'objets de package en exécutant des instructions Bourne shell. Ces instructions sont fournies en tant qu'objet de package. Les instructions s'exécutent automatiquement lors de l'installation si l'objet de package appartient à la classe build.

Le nom du script d'action de classe build doit être identique au nom du fichier sur lequel les instructions sont exécutées. Le nom doit également pouvoir être exécuté par la commande sh. Le résultat du script devient la nouvelle version du fichier à mesure qu'il est créé ou modifié. Si le script ne produit aucun résultat, le fichier n'est ni créé ni modifié. De ce fait, le script peut modifier ou créer le fichier.

Par exemple, si un package fournit un fichier par défaut, /etc/randomtable, qui n'existe pas encore sur le système cible, l'entrée du fichier prototype peut être comme suit :


e build /etc/randomtable ? ? ?

L'objet de package, /etc/randomtable, peut être comme suit :


!install
# randomtable builder
if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then
		echo "/etc/randomtable is already in place.";
	    else
		echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable
		echo "1121554	# first random number" >> $PKG_INSTALL_ROOT/etc/randomtable
fi
 
!remove
# randomtable deconstructor
if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then
		# the file can be removed if it's unchanged
		if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then
			rm $PKG_INSTALL_ROOT/etc/randomtable;
		fi
fi

Reportez-vous au Chapitre5Création d'un package : Études de cas pour consulter un autre exemple utilisant la classe build.

Script de classe preserve

La classe preserve conserve un fichier d'objets de package en déterminant si un fichier existant doit ou non être remplacé à l'installation du package. Deux des scénarios possibles avec l'utilisation du script de classe preserve sont :

Le résultat des deux scénarios est considéré comme positif par le script preserve. Un message d'erreur s'affiche uniquement dans le deuxième scénario si le fichier ne peut pas être copié dans le répertoire cible.

À compter de la version 7 de Solaris, le script i.preserve et une copie de ce script, i.CONFIG.prsv, sont fournis dans le répertoire /usr/sadm/install/scripts avec les autres scripts d'action de classe.

Modifiez le script pour indiquer le nom du ou des fichiers à conserver.

Script de classe manifest

La classe manifest installe et désinstalle automatiquement les services SMF (Service Management Facility) associés à un manifeste SMF. Si vous n'êtes pas familier avec SMF, reportez-vous au Chapitre 17, Managing Services (Overview) du System Administration Guide: Basic Administration pour plus d'informations sur la gestion des services à l'aide de SMF.

Tous les manifestes de service contenus dans les packages doivent être identifiés avec la classe manifest. Les scripts d'action de classe qui installent et suppriment les manifestes de service sont inclus dans le sous-système du package. Lorsque la commande pkgadd(1M) est invoquée, le manifeste du service est importé. Lorsque la commande pkgrm(1M) est invoquée, les instances contenues dans le manifeste du service qui sont désactivées sont supprimées. Tous les services contenus dans le manifeste et pour lesquels il n'existe plus aucune instance sont également supprimés. Si l'option -R est ajoutée à la commande pkgadd(1M) ou pkgrm(1M), ces actions de manifeste de service sont effectuées à la prochaine réinitialisation du système avec cet autre chemin racine.

La portion de code suivante provient d'un fichier d'information de package et illustre l'utilisation de la classe manifest.

# packaging files
i pkginfo
i copyright
i depend
i preinstall
i postinstall
i i.manifest
i r.manifest
#
# source locations relative to the prototype file
#
d none var 0755 root sys
d none var/svc 0755 root sys
d none var/svc/manifest 0755 root sys
d none var/svc/manifest/network 0755 root sys
d none var/svc/manifest/network/rpc 0755 root sys
f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys

ProcedureProcédure de rédaction de scripts d'action de classe

  1. Faites du répertoire contenant vos fichiers d'information votre répertoire de travail actuel.

  2. Donnez aux objets du package le nom de classe souhaité dans le fichier prototype.

    Par exemple, l'attribution des noms de classe application et manpage à des objets est comme suit :


    f manpage /usr/share/man/manl/myappl.1l
f application /usr/bin/myappl

  3. Modifiez le paramètre CLASSES figurant dans le fichier pkginfo afin qu'il contienne les noms de classe à utiliser dans votre package.

    Par exemple, des entrées pour les classes application et manpage sont comme suit :


    CLASSES=manpage application none
    Remarque –

    La classe none est toujours installée en premier et supprimée en dernier, indépendamment de son emplacement dans la définition du paramètre CLASSES.

  4. Si vous créez un script d'action de classe pour un fichier appartenant à la classe sed, awk ou build, faites du répertoire contenant l'objet de package votre répertoire de travail.

  5. Créez les scripts d'action de classe ou les objets de package (pour les fichiers appartenant à la classe sed, awk ou build).

    Par exemple, un script d'installation pour une classe nommée application doit être nommé i.application et un script de suppression, r.application.

    N'oubliez pas que lorsqu'un fichier appartient à une classe associée à un script d'action de classe, le script doit installer le fichier. La commande pkgadd n'installe pas les fichiers pour lesquels un script d'action de classe existe, bien qu'elle vérifie leur installation. De plus, si vous définissez une classe sans fournir de script d'action de classe, la seule opération effectuée sur cette classe est la copie de composants, du support d'installation au système cible (comportement pkgadd par défaut).

  6. Effectuez l'une des opérations suivantes :

  7. Créez votre package.

    Si nécessaire, reportez-vous à la rubrique Procédure de création d'un package.

Autres ressources

Une fois le package créé, installez-le pour confirmer qu'il s'installe correctement et vérifier son intégrité. Le Chapitre4Vérification et transfert d'un package vous explique comment vérifier l'intégrité du package et décrit sa procédure de transfert sur un support de distribution.