test

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

Au-delà de la tradition

L'approche décrite dans cette section n'est pas applicable à tous les packages mais elle permet d'améliorer les performances lors de l'installation sur un environnement hétérogène. Les packages fournis dans le cadre du système d'exploitation Solaris (packages fournis en standard) sont peu concernés par cette approche ; par contre, les packages non fournis en standard peuvent se servir de l'empaquetage non traditionnel.

La raison pour laquelle les packages réadressables sont recommandés est la prise en charge de la spécification suivante :

Lorsqu'un package est ajouté ou supprimé, les comportements actuels souhaités des produits logiciels restent inchangés.

Les packages non fournis en standard doivent résider dans /opt pour s'assurer que le nouveau package n'interfère pas avec les produits existants.

Informations supplémentaires sur les packages composites

Deux règles doivent être appliquées lors de la création d'un package composite fonctionnel :

En d'autres termes, puisque qu'un objet réadressable peut par définition être installé à tout endroit et fonctionner correctement ainsi, aucun script de démarrage exécuté par init lors de l'initialisation ne peut être considéré comme réadressable. Bien que spécifier /etc/passwd en tant que chemin relatif dans le package livré n'est en soi pas incorrect, il ne peut y avoir qu'une destination.

Noms de chemins absolus à l'apparence réadressable

Lorsque vous créez un package composite, les chemins absolus doivent fonctionner sans interférer avec les logiciels déjà installés. Un package pouvant être intégralement contenu dans /opt évite ce problème puisque aucun fichier ne représente un obstacle. Lorsqu'un fichier placé dans /etc est inclus dans le package, vous devez vous assurer que les noms de chemins absolus se comportent comme des noms de chemins relatifs. Réfléchissez aux deux exemples suivants :

Exemple : Modification d'un fichier

Description

Une entrée est ajoutée à un tableau ou l'objet est un nouveau tableau susceptible d'être modifié par d'autres programmes ou packages.

Implémentation

Définissez l'objet comme ayant le type de fichier e et appartenant à la classe build, awk ou sed. Le script effectuant cette opération doit se supprimer aussi efficacement qu'il s'ajoute.

Exemple

Une entrée doit être ajoutée à /etc/vfstab pour prendre en charge le nouveau disque dur électronique.

L'entrée dans le fichier pkgmap pourrait être : 


1 e sed /etc/vfstab ? ? ?

Le script request demande à l'opérateur si /etc/vfstab doit être modifié par le package. Si l'opérateur répond par la négative, le script request imprime les instructions de la procédure manuelle et exécute : 


echo "CLASSES=none" >> $1

Si l'opérateur répond par l'affirmative, il exécute : 


echo "CLASSES=none sed" >> $1

Ceci active le script d'action de classe qui doit apporter les modifications requises. La classe sed indique que le fichier de package /etc/vfstab est un programme sed qui contient les procédures d'installation et de suppression du fichier du même nom sur le système cible.

Exemple : Création d'un fichier

Description

L'objet est un fichier entièrement nouveau peu susceptible d'être modifié ultérieurement ou un fichier qui en remplace un autre appartenant à un package différent.

Implémentation

Définissez l'objet de package comme ayant le type de fichier f et installez-le à l'aide d'un script d'action de classe capable d'annuler la modification.

Exemple

Un tout nouveau fichier est nécessaire dans /etc afin de fournir les informations requises pour la prise en charge du disque dur électronique, appelé /etc/shdisk.conf . L'entrée dans le fichier pkgmap peut être : 


 
.
.
.
1 f newetc /etc/shdisk.conf
.
.
.

Le script d'action de classe i.newetc est chargé d'installer ce fichier ainsi que tout autre fichier devant être placé dans /etc. Il vérifie qu'aucun autre fichier ne s'y trouve. Si le répertoire est vide, il y copie tout simplement le fichier. S'il contient déjà un fichier, il le sauvegarde avant d'installer le nouveau fichier. Le script r.newetc supprime ces fichiers et le cas échéant, rétablit les originaux. Vous trouverez ci-après le fragment clé du script d'installation.

# i.newetc
while read src dst; do
	  if [ -f $dst ]; then
	    dstfile=`basename $dst`
	    cp $dst $PKGSAV/$dstfile
	  fi
	  cp $src $dst
done
 
if [ "${1}" = "ENDOFCLASS" ]; then
	  cd $PKGSAV
	  tar cf SAVE.newetc .
	  $INST_DATADIR/$PKG/install/squish SAVE.newetc
fi

Notez que ce script utilise la variable d'environnement PKGSAV pour stocker une sauvegarde du fichier à remplacer. Lorsque l'argument ENDOFCLASS est transmis au script, autrement dit lorsque la commande pkgadd informe le script qu'il s'agit des dernières entrées de cette classe, le script archive et compresse les fichiers enregistrés à l'aide d'un programme de compression privé stocké dans le répertoire d'installation du package.

Bien que l'utilisation de la variable d'environnement PKGSAV ne soit pas fiable pendant la mise à jour d'un package, si le package n'est pas mis à jour (à l'aide d'un patch par exemple), le fichier de sauvegarde est sécurisé. Le script de suppression suivant inclut un code permettant de résoudre le deuxième problème, à savoir, le fait que dans les anciennes versions, la commande pkgrm ne transmet pas aux scripts le bon chemin d'accès à la variable d'environnement PKGSAV .

Le script de suppression peut être comme suit :

# r.newetc
 
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
	  PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
 
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
 
while read file; do
	  rm $file
done
 
if [ "${1}" = ENDOFCLASS ]; then
	  if [ -f $PKGSAV/SAVE.newetc.sq ]; then
	     $UNSQUISH_CMD $PKGSAV/SAVE.newetc
	  fi
 
	  if [ -f $PKGSAV/SAVE.newetc ]; then
	     targetdir=dirname $file	# get the right directory
	     cd $targetdir
		    tar xf $PKGSAV/SAVE.newetc
		    rm $PKGSAV/SAVE.newetc
	  fi
fi

Ce script utilise un algorithme de désinstallation privé (unsquish) situé dans le répertoire d'installation de la base de données des packages. Ceci est automatiquement effectué par la commande pkgadd lors de la phase d'installation. Tous les scripts non spécifiquement reconnus comme ayant l'attribut d'installation seule par la commande pkgadd sont stockés dans ce répertoire afin d'être utilisés par la commande pkgrm. Vous ne pouvez pas compter sur l'emplacement de ce répertoire mais vous pouvez être sûr qu'il est plat et qu'il contient toutes les informations et scripts d'installation appropriés du package. Ce script trouve le répertoire en raison du fait que le script d'action de classe s'exécute systématiquement à partir du répertoire contenant le programme unsquish.

Notez également que ce script ne suppose pas simplement que le répertoire cible est /etc. Il peut en fait s'agir de /export/root/client2/etc . Le répertoire approprié peut être créé de deux façons.

L'utilisation de cette approche pour chaque objet absolu du package vous assure que le comportement actuel souhaité reste inchangé ou qu'il est au moins récupérable.

Exemple : Package composite

L'exemple suivant illustre les fichiers pkginfo et pkgmap d'un package composite.

Fichier pkginfo 

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 daemon
PSTAMP=hubert990707141632

Fichier pkgmap 

: 1 1758
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 d none /etc	? ? ?
1 d none /etc/rc2.d ? ? ?
1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i i.daemon 509 39560 752978103
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
1 i r.daemon 320 24573 742152591

Alors que S70dostuf appartient à la classe daemon, les répertoires qui y accèdent (déjà en place lors de la phase d'installation) appartiennent eux à la classe none. Même si les répertoires étaient uniques à ce package, vous devriez les laisser dans la classe none. Ceci, parce que les répertoires doivent être créés en premier et supprimés en dernier, ce qui est toujours vrai de la classe none. La commande pkgadd crée des répertoires qui ne sont ni copiés à partir du package, ni transmis à un script d'action de classe afin d'être créés. Ils sont par contre créés par la commande pkgadd avant qu'elle n'appelle le script d'action de classe ; la commande pkgrm par ailleurs supprime les répertoires une fois le script d'action de classe de suppression terminé.

De ce fait, lorsqu'un répertoire d'une classe spéciale contient des objets de la classe none, la tentative de suppression du répertoire par la commande pkgrm échoue car le répertoire n'est pas vidé à temps. Si un objet de la classe none doit être inséré dans un répertoire d'une classe spéciale, le répertoire en question n'est pas créé à temps pour recevoir l'objet. La commande pkgadd crée le répertoire à la volée au cours de l'installation de l'objet et ne parvient parfois pas à synchroniser les attributs de ce répertoire lorsqu'elle trouve la définition pkgmap.

Remarque –

Lorsque vous attribuez un répertoire à une classe, pensez toujours à l'ordre de création et de suppression.