test

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

Chapitre 5 Création d'un package : Études de cas

Ce chapitre présente des études de cas permettant d'illustrer divers scénarios d'empaquetage, notamment l'installation d'objets de manière conditionnelle, la prise de décision lors de l'exécution du nombre de fichiers à créer et la modification d'un fichier de données existant au cours de l'installation et de la suppression d'un package.

Chaque étude de cas commence par une description, suivie d'une liste de techniques d'empaquetage utilisées, d'une description de la démarche à suivre pour appliquer ces techniques et d'exemples de fichiers et de scripts associés à l'étude de cas.

Les études de cas décrites dans ce chapitre sont les suivantes :

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 :

Démarche

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

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 de 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.

Création d'un fichier lors de l'installation et enregistrement du fichier lors de la suppression

Cette étude de cas crée un fichier de base de données lors de la phase d'installation et enregistre une copie de la base de données à la suppression du package.

Techniques

Cette étude de cas illustre les techniques suivantes :

Démarche

Pour créer un fichier de base de données lors de l'installation et enregistrer une copie lors de la suppression, vous devez pour cette étude de cas effectuer les opérations suivantes :

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=krazy
NAME=KrAzY Applications
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1
CLASSES=none cfgdata admin

Fichier prototype 

i pkginfo
i request
i i.admin
i r.cfgdata
d none bin 555 root sys
f none bin/process1 555 root other
f none bin/process2 555 root other
f none bin/process3 555 root other
f admin bin/config 500 root sys
d admin cfg 555 root sys
f admin cfg/datafile1 444 root sys
f admin cfg/datafile2 444 root sys
f admin cfg/datafile3 444 root sys
f admin cfg/datafile4 444 root sys
d cfgdata data 555 root sys

Fichier space 

# extra space required by config data which is
# dynamically loaded onto the system
data 500 1

Script d'action de classe i.admin 

# PKGINST parameter provided by installation service
# BASEDIR parameter provided by installation service
while read src dest
do
   cp $src $dest || exit 2
done
# if this is the last time this script will be executed
# during the installation, do additional processing here.
if [ "$1" = ENDOFCLASS ]
then
# our config process will create a data file based on any changes
# made by installing files in this class; make sure the data file
# is in class `cfgdata' so special rules can apply to it during
# package removal.
   installf -c cfgdata $PKGINST $BASEDIR/data/config.data f 444 root
   sys || exit 2
   $BASEDIR/bin/config > $BASEDIR/data/config.data || exit 2
   installf -f -c cfgdata $PKGINST || exit 2
fi
exit 0

Cet exemple illustre une situation rare dans laquelle installf est approprié dans un script d'action de classe. Le fichier space ayant été utilisé pour réserver de l'espace sur un système de fichiers spécifique, ce nouveau fichier peut être ajouté sans problèmes bien qu'il ne soit pas inclus dans le fichier pkgmap.

Script de suppression r.cfgdata 

# the product manager for this package has suggested that
# the configuration data is so valuable that it should be
# backed up to $PKGSAV before it is removed!
while read path
do
# path names appear in reverse lexical order.
   mv $path $PKGSAV || exit 2
   rm -f $path || exit 2
done
exit 0

Définition des compatibilités et des dépendances d'un package

Le package de cette étude de cas utilise des fichiers d'information facultatifs pour définir les compatibilités et les dépendances d'un package, et afficher un message de copyright au cours de l'installation.

Techniques

Cette étude de cas illustre les techniques suivantes :

Pour plus d'informations sur ces fichiers, reportez-vous à Création de fichiers d'information.

Démarche

Pour respecter les critères fournis dans la description, vous devez :

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=case3
NAME=Case Study #3
CATEGORY=application
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 3.0
CLASSES=none

Fichier copyright 

Copyright (c) 1999 company_name
All Rights Reserved.
THIS PACKAGE CONTAINS UNPUBLISHED PROPRIETARY SOURCE CODE OF
company_name.
The copyright notice above does not evidence any
actual or intended publication of such source code

Fichier compver 

Version 3.0
Version 2.3
Version 2.2
Version 2.1
Version 2.1.1
Version 2.1.3
Version 1.7

Fichier depend 

P acu Advanced C Utilities
Issue 4 Version 1
P cc C Programming Language
Issue 4 Version 1
P dfm Directory and File Management Utilities
P ed Editing Utilities
P esg Extended Software Generation Utilities
Issue 4 Version 1
P graph Graphics Utilities
P rfs Remote File Sharing Utilities
Issue 1 Version 1
P rx Remote Execution Utilities
P sgs Software Generation Utilities
Issue 4 Version 1
P shell Shell Programming Utilities
P sys System Header Files
Release 3.1

Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe

Cette étude de cas modifie un fichier existant lors de l'installation d'un package à l'aide de classes standard et de scripts d'action de classe. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de la classe sed et d'un script postinstall et Modification d'un fichier à l'aide de la classe build. Le fichier modifié est /etc/inittab .

Techniques

Cette étude de cas illustre la façon d'utiliser les scripts d'action de classe d'installation et de suppression. Pour plus d'informations, reportez-vous à Rédaction de scripts d'action de classe.

Démarche

Pour modifier /etc/inittab au cours de l'installation à l'aide de classes et de scripts d'action de classe, vous devez effectuer les opérations suivantes :

Cette étude de cas est plus complexe que la suivante ; reportez-vous à Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Au lieu de fournir deux fichiers, trois sont nécessaires et le fichier /etc/inittab fourni n'est qu'un substituant contenant un segment de l'entrée à insérer. Ce segment aurait pu être placé dans le fichier i.inittab mais la commande pkgadd doit avoir un fichier à transmettre au fichier i.inittab. En outre, la procédure de suppression doit être placée dans un fichier distinct (r.inittab ). Bien que cette méthode fonctionne bien, il est recommandé de la réserver aux situations impliquant l'installation complexe de plusieurs fichiers. Reportez-vous à Modification de fichiers crontab au cours de l'installation.

Le programme sed utilisé dans Modification d'un fichier à l'aide de la classe sed et d'un script postinstall prend en charge plusieurs instances d'un package puisque le commentaire situé à la fin de l'entrée inittab se base sur l'instance d'un package. L'étude de cas de la rubrique Modification d'un fichier à l'aide de la classe build illustre une démarche plus rationalisée de modification du fichier /etc/inittab pendant l'installation.

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=case5
NAME=Case Study #5
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=inittab

Fichier prototype 

i pkginfo
i i.inittab
i r.inittab
e inittab /etc/inittab ? ? ?

Script d'action de classe d'installation i.inittab 

# PKGINST parameter provided by installation service
while read src dest
do
# remove all entries from the table that
# associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest >
/tmp/$$itab ||
exit 2
sed -e "s/$/#$PKGINST" $src >> /tmp/$$itab ||
exit 2
mv /tmp/$$itab $dest ||
exit 2
done
if [ "$1" = ENDOFCLASS ]
then
/sbin/init q ||
exit 2
fi
exit 0

Script d'action de classe de suppression r.inittab 

# PKGINST parameter provided by installation service
while read src dest
do
# remove all entries from the table that
# are associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest >
/tmp/$$itab ||
exit 2
mv /tmp/$$itab $dest ||
exit 2
done
/sbin/init q ||
exit 2
exit 0

Fichier inittab 

rb:023456:wait:/usr/robot/bin/setup

Modification d'un fichier à l'aide de la classe sed et d'un script postinstall

Cette étude de cas modifie un fichier présent sur la machine d'installation lors de l'installation du package. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe build. Le fichier modifié est /etc/inittab.

Techniques

Cette étude de cas illustre les techniques suivantes :

Démarche

Pour modifier /etc/inittab lors de l'installation à l'aide de la classe sed, vous devez effectuer les opérations suivantes :

Cette démarche de modification du fichier /etc/inittab lors de l'installation présente un inconvénient ; elle nécessite un script complet (le script postinstall) pour la simple exécution de la commande init q.

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=case4
NAME=Case Study #4
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=sed

Fichier prototype 

i pkginfo
i postinstall
e sed /etc/inittab ? ? ?

Script d'action de classe sed (/etc/inittab)

!remove
# remove all entries from the table that are associated
# with this package, though not necessarily just
# with this package instance
/^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d
!install
# remove any previous entry added to the table
# for this particular change
/^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d
# add the needed entry at the end of the table;
# sed(1) does not properly interpret the '$a'
# construct if you previously deleted the last
# line, so the command
# $a\
# rb:023456:wait:/usr/robot/bin/setup #ROBOT
# will not work here if the file already contained
# the modification. Instead, you will settle for
# inserting the entry before the last line!
$i\
rb:023456:wait:/usr/robot/bin/setup #ROBOT

Script postinstall 

# make init re-read inittab
/sbin/init q ||
exit 2
exit 0

Modification d'un fichier à l'aide de la classe build

Cette étude de cas modifie un fichier présent sur la machine d'installation lors de l'installation du package. Elle utilise une des trois méthodes de modification disponibles. Les deux autres méthodes sont décrites dans les rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Le fichier modifié est /etc/inittab.

Techniques

Cette étude de cas illustre l'utilisation de la classe build. Pour plus d'informations sur la classe build, reportez-vous à Script de classe build.

Démarche

Cette démarche de modification du fichier /etc/inittab utilise la classe build. Un script de classe build est exécuté comme un script shell et son résultat devient la nouvelle version du fichier exécuté. Autrement dit, le fichier de données /etc/inittab fourni avec ce package est exécuté et le résultat de cette exécution devient /etc/inittab.

Le script de classe build est exécuté lors de l'installation et de la suppression du package. L'argument install est transmis au fichier s'il est exécuté lors de la phase d'installation. Remarquez dans l'exemple de script de classe build que la procédure d'installation est définie en testant cet argument.

Pour modifier /etc/inittab à l'aide de la classe build, vous devez effectuer les opérations suivantes :

Cette solution résout les inconvénients décrits dans les études de cas des rubriques Modification d'un fichier à l'aide de classes standard et de scripts d'action de classe et Modification d'un fichier à l'aide de la classe sed et d'un script postinstall. Seul un bref fichier est nécessaire (outre les fichiers pkginfo et prototype). Le fichier fonctionne avec plusieurs instances d'un package puisque le paramètre PKGINST est utilisé ; par ailleurs, aucun script postinstall n'est requis puisque la commande init q peut être exécutée à partir du script de classe build.

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=case6
NAME=Case Study #6
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=build

Fichier prototype 

i pkginfo
e build /etc/inittab ? ? ?

Fichier de version

# PKGINST parameter provided by installation service
# remove all entries from the existing table that
# are associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab ||
exit 2
if [ "$1" = install ]
then
# add the following entry to the table
echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" ||
exit 2
fi
/sbin/init q ||
exit 2
exit 0

Modification de fichiers crontab au cours de l'installation

Cette étude de cas modifie les fichiers crontab lors de l'installation du package.

Techniques

Cette étude de cas illustre les techniques suivantes :

Démarche

La manière la plus efficace de modifier plusieurs fichiers lors de l'installation consiste à définir une classe et à fournir un script d'action de classe. Si vous avez utilisé la démarche de la classe build, vous devez fournir un script de classe build pour chaque fichier crontab modifié. La définition d'une classe cron représente une démarche plus globale. Pour modifier les fichiers crontaben suivant cette démarche, vous devez effectuer les opérations suivantes :

Fichiers de l'étude de cas

Les scripts i.cron et r.cron décrits ci-après sont exécutés par le superutilisateur. Modifier le fichier crontab d'un autre superutilisateur peut avoir des conséquences imprévisibles. Si nécessaire, remplacez l'entrée suivante de chaque script :

crontab $user < /tmp/$$crontab ||

par celle-ci :

su $user -c "crontab /tmp/$$crontab" ||

Commande pkginfo 

PKG=case7
NAME=Case Study #7
CATEGORY=application
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1.0
CLASSES=cron

Fichier prototype 

i pkginfo
i i.cron
i r.cron
e cron /var/spool/cron/crontabs/root ? ? ?
e cron /var/spool/cron/crontabs/sys ? ? ?

Script d'action de classe d'installation i.cron 

# PKGINST parameter provided by installation service
while read src dest
do
user=`basename $dest` ||
exit 2
(crontab -l $user |
sed -e "/#$PKGINST$/d" > /tmp/$$crontab) ||
exit 2
sed -e "s/$/#$PKGINST/" $src >> /tmp/$$crontab ||
exit 2
crontab $user < /tmp/$$crontab ||
exit 2
rm -f /tmp/$$crontab
done
exit 0

Script d'action de classe de suppression r.cron 

# PKGINST parameter provided by installation service
while read path
do
user=`basename $path` ||
exit 2
(crontab -l $user |
sed -e "/#$PKGINST$/d" > /tmp/$$crontab) ||
exit 2
crontab $user < /tmp/$$crontab ||
exit 2
rm -f /tmp/$$crontab
done
exit

Premier fichier crontab 

41,1,21 * * * * /usr/lib/uucp/uudemon.hour > /dev/null
45 23 * * * ulimit 5000; /usr/bin/su uucp -c
"/usr/lib/uucp/uudemon.cleanup" >
/dev/null 2>&1
11,31,51 * * * * /usr/lib/uucp/uudemon.poll > /dev/null

Deuxième fichier crontab 

0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
Remarque –

Si la modification d'un groupe de fichiers augmente la taille globale des fichiers de plus de 10 Ko, fournissez un fichier space pour que la commande pkgadd puisse accommoder cette augmentation. Pour plus d'informations sur le fichier space, reportez-vous à Réservation d'espace supplémentaire sur un système cible.

Installation et suppression d'un pilote à l'aide de scripts de procédure

Ce package installe un pilote.

Techniques

Cette étude de cas illustre les techniques suivantes :

Pour plus d'informations sur ces scripts, reportez-vous à Rédaction de scripts de procédure.

Démarche

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=bufdev
NAME=Buffer Device
CATEGORY=system
BASEDIR=/
ARCH=INTEL
VERSION=Software Issue #19
CLASSES=none

Fichier prototype

Pour installer un pilote lors de l'installation, vous devez inclure les fichiers d'objets et de configuration du pilote dans le fichier prototype.

Dans cet exemple, le module exécutable du pilote est nommé buffer ; la commande add_drv opère sur ce fichier. Le noyau utilise le fichier de configuration, buffer.conf pour aider à configurer le pilote. 

i pkginfo
i request
i postinstall
i preremove
f none $KERNDIR/buffer 444 root root
f none $KERNDIR/buffer.conf 444 root root

Remarquez les points suivants dans le fichier prototype de cet exemple :

Script request 

trap 'exit 3' 15
# determine where driver object should be placed; location
# must be an absolute path name that is an existing directory
KERNDIR=`ckpath -aoy -d /kernel/drv -p \
“Where do you want the driver object installed”` || exit $?

# make parameters available to installation service, and
# so to any other packaging scripts
cat >$1 <<!

CLASSES='$CLASSES'
KERNDIR='$KERNDIR'
!
exit 0

Script postinstall 

# KERNDIR parameter provided by `request' script
err_code=1                    # an error is considered fatal
# Load the module into the system
cd $KERNDIR
add_drv -m '* 0666 root sys' buffer || exit $err_code
# Create a /dev entry for the character node
installf $PKGINST /dev/buffer0=/devices/eisa/buffer*:0 s
installf -f $PKGINST

Script preremove 

err_code=1                    # an error is considered fatal
# Unload the driver
rem_drv buffer || exit $err_code
# remove /dev file
removef $PKGINST /dev/buffer0 ; rm /dev/buffer0
removef -f $PKGINST

Installation d'un pilote à l'aide de la classe sed et de scripts de procédure

Cette étude de cas décrit l'installation d'un pilote à l'aide de la classe sed et de scripts de procédure. Elle diffère par ailleurs de l'étude de cas précédente (reportez-vous à Installation et suppression d'un pilote à l'aide de scripts de procédure) sur le fait que ce package est composé à la fois d'objets absolus et d'objets réadressables.

Techniques

Cette étude de cas illustre les techniques suivantes :

Démarche

Fichiers de l'étude de cas

Fichier pkginfo 

PKG=SUNWsst
NAME=Simple SCSI Target Driver
VERSION=1
CATEGORY=system
ARCH=sparc
VENDOR=Sun Microsystems
BASEDIR=/opt
CLASSES=sed

Fichier prototype

Par exemple, cette étude de cas utilise la structure hiérarchique des objets de package illustrée ci-après.

Figure 5–1 Structure du répertoire d'un package hiérarchique

Le contexte suivant décrit le graphique.

Les objets du package sont installés dans les mêmes fichiers que sur l'illustration du répertoire pkg ci-dessus. Les modules du pilote ( sst et sst.conf) sont installés dans /usr/kernel/drv et le fichier include est installé dans /usr/include/sys/scsi/targets. Les fichiers sst, sst.conf et sst_def.h sont des objets absolus. Le programme test sstest.c et son répertoire SUNWsst sont tous deux réadressables ; leur emplacement d'installation est défini par le paramètre BASEDIR.

Les autres composants du package (tous les fichiers de contrôle) doivent être placés dans le répertoire supérieur du package sur la machine de développement, à l'exception du script de la classe sed . Celui-ci est appelé devlink.tab d'après le nom du fichier qu'il modifie et doit être placé dans etc, répertoire contenant le vrai fichier devlink.tab.

À partir du répertoire pkg, exécutez la commande pkgproto comme suit :


find usr SUNWsst -print | pkgproto > prototype

Le résultat de la commande ci-dessus est comme suit :

d none usr 0775 pms mts
d none usr/include 0775 pms mts
d none usr/include/sys 0775 pms mts
d none usr/include/sys/scsi 0775 pms mts
d none usr/include/sys/scsi/targets 0775 pms mts
f none usr/include/sys/scsi/targets/sst_def.h 0444 pms mts
d none usr/kernel 0775 pms mts
d none usr/kernel/drv 0775 pms mts
f none usr/kernel/drv/sst 0664 pms mts
f none usr/kernel/drv/sst.conf 0444 pms mts
d none SUNWsst 0775 pms mts
f none SUNWsst/sstest.c 0664 pms mts

Le fichier prototype n'est pas encore terminé. Pour terminer le fichier, vous devez lui apporter les modifications suivantes :

Fichier prototype final :

i pkginfo
i postinstall
i preremove
i copyright
e sed /etc/devlink.tab ? ? ?
f none /usr/include/sys/scsi/targets/sst_def.h 0644 bin bin
f none /usr/kernel/drv/sst 0755 root sys
f none /usr/kernel/drv/sst.conf 0644 root sys
d none SUNWsst 0775 root sys
f none SUNWsst/sstest.c 0664 root sys

Les points d'interrogation de l'entrée correspondant au script sed indiquent que les droits d'accès et la propriété du fichier présent sur la machine d'installation ne doivent pas être modifiés.

Script d'action de classe sed (/etc/devlink.tab)

Dans l'exemple de pilote, un script de classe sed est utilisé pour ajouter une entrée correspondant au pilote dans le fichier /etc/devlink.tab. Ce fichier est utilisé par la commande devlinks pour créer des liens symboliques de /dev à /devices. Script sed :

# sed class script to modify /etc/devlink.tab
!install
/name=sst;/d
$i\
type=ddi_pseudo;name=sst;minor=character	rsst\\A1

!remove
/name=sst;/d

La commande pkgrm n'exécute pas la partie du script correspondant à la suppression. Il s'avère parfois nécessaire d'ajouter une ligne au script preremove afin d'exécuter sed directement pour supprimer l'entrée du fichier /etc/devlink.tab.

Script d'installation postinstall

Dans cet exemple, il suffit au script d'exécuter la commande add_drv.

# Postinstallation script for SUNWsst
# This does not apply to a client.
if [$PKG_INSTALL_ROOT = "/" -o -z $PKG_INSTALL_ROOT]; then
   SAVEBASE=$BASEDIR
   BASEDIR=””; export BASEDIR
   /usr/sbin/add_drv sst
   STATUS=$?
   BASEDIR=$SAVEBASE; export BASEDIR
   if [ $STATUS -eq 0 ]
   then
	     exit 20
   else
	     exit 2
   fi
else
   echo "This cannot be installed onto a client."
   exit 2
fi

La commande add_drv utilise le paramètre BASEDIR ; le script doit pour cette raison annuler la valeur définie pour BASEDIR avant d'exécuter la commande et la rétablir après l'exécution.

Une des opérations effectuées par la commande add_drv est l'exécution de devlinks qui utilise l'entrée placée dans /etc/devlink.tab par le script de classe sed pour créer les entrées /dev correspondant au pilote.

Le code de sortie du script postinstall est significatif. Le code de sortie 20 indique à la commande pkgadd de demander à l'utilisateur de réinitialiser le système (opération nécessaire après l'installation d'un pilote) et le code de sortie 2 indique à la commande pkgadd d'informer l'utilisateur que l'installation a partiellement échoué.

Script de suppression preremove

Dans cet exemple de pilote, il supprime les liens figurant dans /dev et exécute la commande rem_drv sur le pilote.

# Pre removal script for the sst driver
echo “Removing /dev entries”
/usr/bin/rm -f /dev/rsst*

echo “Deinstalling driver from the kernel”
SAVEBASE=$BASEDIR
BASEDIR=””; export BASEDIR
/usr/sbin/rem_drv sst
BASEDIR=$SAVEBASE; export BASEDIR

exit

Le script supprime lui-même les entrées /dev alors que les entrées /devices sont supprimées par la commande rem_drv.

Fichier copyright

Ce fichier est un simple fichier ASCII contenant le texte d'un avis de copyright. L'avis s'affiche au début de l'installation du package tel qu'il apparaît dans le fichier.


	Copyright (c) 1999 Drivers-R-Us, Inc.
	10 Device Drive, Thebus, IO 80586

All rights reserved. This product and related documentation is
protected by copyright and distributed under licenses 
restricting its use, copying, distribution and decompilation. 
No part of this product or related documentation may be 
reproduced in any form by any means without prior written 
authorization of Drivers-R-Us and its licensors, if any.