Logiciel de conditionnement pour l'installation

Exigences relatives à la procédure d'installation

Exigences en matière d'information sur le contrôle des colis

Les informations de contrôle de package doivent:

• Spécifiez toutes les exigences d'installation que les jeux de fichiers ont sur d'autres jeux de fichiers.
• Indiquez toutes les exigences de taille de système de fichiers pour l'installation de l'ensemble de fichiers.

Format d'un logiciel

Un paquet d'installation ou de mise à jour doit être un fichier unique au format de sauvegarde qui peut être restauré par la commande " installp pendant l'installation. Ce fichier peut être distribué sur bande, disquette ou CD-ROM.

Exigences en matière de cloisonnement des colis

Pour prendre en charge les postes de travail clients sans disque ou sans données, les parties du paquet spécifiques à la machine (la partie " root ) doivent être séparées des parties du paquet partageables par la machine (la partie "usr"). La partie " usr du paquet contient des fichiers qui résident dans le système de fichiers " /usr ou " /opt

L'installation de la partie " root du paquet ne doit pas modifier les fichiers du système de fichiers " /usr. Le système de fichiers " /usr n'est pas accessible en écriture pendant l'installation de la partie " root d'un système client sans disque ou sans données. La partie spécifique à la machine (racine) doit inclure tout ce qui ne se trouve pas dans les systèmes de fichiers " /usr ou " /opt.

Emballage pour les partitions de la charge de travail

Certains produits logiciels doivent être pris en compte lors de leur conditionnement pour le partitionnement de charge de travail (WPAR). Pour qu'un produit logiciel puisse être déployé avec succès dans un WPAR, il doit être conditionné de telle sorte qu'il ne tente pas d'écrire dans les systèmes de fichiers " /usr ou " /opt pendant la partie " root du traitement, car un WPAR monte ces systèmes de fichiers en mode lecture seule. De même, toute configuration à effectuer dans chaque système où le produit est installé doit être effectuée à partir de la partie " root du paquet.

Si un jeu de fichiers n'est pas destiné à être installé dans une partition de charge de travail, il doit être désigné par l'attribut PRIVATE dans le fichier 'lpp_name du paquet.

Si un ensemble de fichiers doit être configuré différemment lorsqu'il est installé dans une partition de charge de travail (WPAR), un script de conditionnement vérifie la variable d'environnement INUWPAR pour déterminer si l'ensemble de fichiers est installé dans une partition de charge de travail (WPAR).

Si un jeu de fichiers est configuré différemment lorsqu'il est installé dans une WPAR, il est reconfiguré lorsqu'une WPAR est créée à partir d'une copie du système, car le jeu de fichiers n'était pas installé dans une WPAR à l'origine. Les propriétaires de jeux de fichiers peuvent créer des programmes dans les répertoires " /usr/lib/wpars/wparconvert.d/usr et " /usr/lib/wpars/wparconvert.d/root, qui doivent être exécutés lors de la conversion des parties " usr et " root de leur jeu de fichiers pour être exécutés dans une copie système WPAR. Tous les fichiers exécutables de ces répertoires sont exécutés dans l'ordre alphabétique (environnement local C) lors du premier démarrage d'une partition de charge de travail de copie système.

Données techniques essentielles sur les produits logiciels

Les informations relatives à un produit logiciel et à ses options installables sont conservées dans la base de données SWVPD (Software Vital Product Data). SWVPD se compose d'un ensemble de commandes et de classes d'objets Object Data Manager (ODM) pour la maintenance des informations sur les produits logiciels. Les commandes SWVPD permettent à l'utilisateur d'interroger (lslpp) et de vérifier (lppchk) les produits logiciels installés. Les classes d'objets ODM définissent la portée et le format des informations sur les produits logiciels qui sont conservées.

La commande 'installp utilise le gestionnaire de données d'objets pour maintenir les informations suivantes dans la base de données SWVPD :

• Le nom du produit logiciel (par exemple, " bos.adt)
• Version du produit logiciel
• Niveau d'édition du produit logiciel, qui indique les modifications apportées à l'interface de programmation externe du produit logiciel
• Niveau de modification du produit logiciel, qui indique les modifications qui n'affectent pas l'interface externe du produit logiciel
• Le niveau de correction du produit logiciel, qui indique les petites mises à jour qui seront intégrées ultérieurement dans un niveau de modification régulier
• Nom, total de contrôle et taille des fichiers qui composent le produit logiciel ou l'option
• Etat du produit logiciel: disponible, application, appliqué, validation, validé, rejeté ou rompu
• Niveau de technologie et informations sur les APAR
• Répertoire de destination et programme d'installation pour les logiciels non installp conditionnés, le cas échéant.

Pièces d'emballage de produits logiciels

Exemple de guide du système de fichiers pour le partitionnement des paquets

Voici une brève description des systèmes de fichiers et des répertoires. Vous pouvez l'utiliser comme guide pour fractionner un package de produit en composants racine, usr et de partage.

Conventions de dénomination des paquets et des jeux de fichiers

Considérations particulières concernant la dénomination des pilotes de périphériques

La commande du gestionnaire de configuration (cfgmgr) installe automatiquement la prise en charge logicielle des dispositifs détectables disponibles sur le support d'installation et présentés selon la convention d'appellation suivante :

devices.BusTypeID.CardID.Extension

où :

• BusTypeID spécifie le type de bus auquel la carte se rattache (par exemple, pci pour PCI
• CardID spécifie l'identifiant hexadécimal unique associé au type de carte
• L'extension spécifie la partie du pilote qui est incluse (par exemple, rte peut être l'extension pour la durée d'exécution et diag est l'extension pour les diagnostics)

Par exemple, supposons qu'un périphérique Ethernet se connecte au bus PCI et est identifié par le gestionnaire de configuration comme ayant un identifiant de carte unique " 1410bb02. Le paquet de jeux de fichiers associé à ce périphérique Ethernet est appelé " devices.pci.1410bb02. Le jeu de fichiers de l'environnement d'exécution de ce paquet serait nommé " devices.pci.1410bb02.rte.

Considérations particulières concernant la dénomination des emballages des catalogues de messages

Un utilisateur qui installe un package peut demander que les catalogues de messages soient installés automatiquement. Lorsque cette demande est effectuée, le système installe automatiquement les ensembles de fichiers de messages pour la langue principale si les ensembles de fichiers de messages sont disponibles sur le support d'installation et fournis avec la convention de dénomination suivante:

Product.msg.Language.SubProduct

Le suffixe optionnel.SubProduct est utilisé lorsqu'un produit a plusieurs jeux de fichiers de catalogue de messages pour la même langue, chaque jeu de fichiers de catalogue de messages s'appliquant à un SubProduct différent. Vous pouvez choisir d'avoir un ensemble de fichiers de messages pour un produit entier.

Par exemple, le produit " Super_Widget a un ensemble d'options de jeu de fichiers " plastic et " metal Tous les catalogues de messages anglais américains " Super_Widget peuvent être regroupés dans un seul jeu de fichiers appelé " Super_Widget.msg.en_US. Si des jeux de fichiers distincts sont nécessaires pour les options " plastic et " metal, les jeux de fichiers du catalogue de messages en anglais seront nommés " Super_Widget.msg.en_US.plastic et " Super_Widget.msg.en_US.metal.

Remarque : un jeu de fichiers de messages conforme à cette convention d'appellation doit contenir un prérequis installé (instreq) sur un autre jeu de fichiers du produit afin de garantir l'installation automatique du jeu de fichiers de messages.

Noms de fichier

Les fichiers livrés avec le logiciel ne peuvent pas avoir de noms contenant des virgules ou des deux-points. Les virgules et les deux-points sont utilisés comme délimiteurs dans les fichiers de contrôle utilisés lors du processus d'installation du logiciel. Les noms de fichier peuvent contenir des caractères non ASCII. Le chemin d'accès complet au nom de fichier ne peut pas comporter plus de 128 caractères.

Identification du niveau de révision du jeu de fichiers

Le niveau du jeu de fichiers est appelé niveau ou encore v.r.m.f ou VRMF et se présente sous la forme suivante :

Version.Release.Modification.FixLevel

où :

• Version est une zone numérique de 1 à 2 chiffres qui identifie le numéro de version.
• Edition est une zone numérique de 1 à 2 chiffres qui identifie le numéro d'édition.
• Modification est une zone numérique de 1 à 4 chiffres qui identifie le niveau de modification.
• FixLevel est une zone numérique de 1 à 4 chiffres qui identifie le niveau de correctif.

Le niveau d'installation d'un jeu de fichiers de base est le niveau d'installation initial complet d'un jeu de fichiers. Ce niveau contient tous les fichiers de l'ensemble de fichiers, contrairement à une mise à jour de l'ensemble de fichiers, qui peut contenir un sous-ensemble de fichiers de l'ensemble de fichiers complet.

Tous les jeux de fichiers d'un logiciel doivent avoir le même niveau de jeu de fichiers, bien que cela ne soit pas nécessaire pour les paquets formatés en " AIX 4.1

Pour tous les nouveaux niveaux d'un ensemble de fichiers, le niveau de l'ensemble de fichiers doit augmenter. La commande " installp utilise le niveau du jeu de fichiers pour vérifier la présence d'un niveau ultérieur du produit lors d'installations ultérieures.

le niveau de préséance du jeu de fichiers se lit de gauche à droite (par exemple, " 5.2.0.0 est un niveau plus récent que " 4.3.0.0).

Contenu d'un logiciel

Cette section décrit les fichiers contenus dans un paquet d'installation ou de mise à jour. Les noms de chemin d'accès aux fichiers sont indiqués pour les types de module d'installation. Pour les paquets de mise à jour, lorsque PackageName fait partie du nom du chemin, il est remplacé par " PackageName/FilesetName/FilesetLevel.

Exemple de contenu d'un logiciel

Le paquet " farm.apps contient le jeu de fichiers " farm.apps.hog 4.1.0.0. Le jeu de fichiers 'farm.apps.hog 4.1.0.0 contient les fichiers suivants :

/usr/bin/raisehog (in the usr part of the package)
/usr/sbin/sellhog
 (in the usr part of the package)

/etc/hog
 (in the root part of the package)

Le paquet " farm.apps contient au moins les fichiers suivants :

./lpp_name
./usr/lpp/farm.apps/liblpp.a
./usr/lpp/farm.apps/inst_root/liblpp.a
./usr/bin/raisehog
./usr/sbin/sellhog
./usr/lpp/farm.apps/inst_root/etc/hog

La mise à jour du jeu de fichiers 'farm.apps.hog 4.1.0.3 fournit des mises à jour pour les fichiers suivants :

/usr/sbin/sellhog
/etc/hog

Le package de mise à jour de l'ensemble de fichiers contient les fichiers suivants:

./lpp_name
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/liblpp.a
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/liblpp.a
./usr/sbin/sellhog
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/etc/hog

Note : Le fichier de la partie " root du paquet a été restauré dans un répertoire " inst_root. Les fichiers installés pour la partie " root d'un paquet, qui dépend de la machine, sont restaurés par rapport à un répertoire " inst_root. Cela facilite l'installation de fichiers spécifiques à la machine dans les systèmes de fichiers " root de plusieurs systèmes. Les fichiers de la partie " root sont installés dans les parties " root des systèmes en copiant les fichiers du répertoire " inst_root. Cela permet à plusieurs machines de partager une partie commune " usr indépendante de la machine.

Le fichier d'information sur le paquet lpp_name

Chaque logiciel doit contenir le fichier d'information " lpp_name. Le fichier 'lpp_name donne à la commande 'installp des informations sur le paquet et sur chaque jeu de fichiers du paquet. La figure présente un exemple de fichier " lpp_name pour un paquet de mise à jour d'un jeu de fichiers. Les nombres et les flèches de la figure font référence aux zones décrites dans le tableau qui suit.

Exemple

1 23    4
| ||    |                6         7 8 9  10       11
4 RSfarm.apps {  |       |         | | |   |        |
5--> farm.apps.hog04.01.0000.0003 1 N U en_US Hog Utilities 
12--># ...      
[
13--> *ifreq bos.farming.rte (4.2.0.0) 4.2.0.15
%
14--> /usr/sbin 48
14--> /usr/lpp/farm.apps/farm.apps.hog/4.1.0.3 280
14--> /usr/lpp/farm.apps/farm.apps.hog/inst_root/4.1.0.3.96
14--> /usr/lpp/SAVESPACE 48
14--> /lpp/SAVESPACE 32
14--> /usr/lpp/bos.hos/farm.apps.hog/inst_root/4.1.0.3/ etc 32
%
%
15--> ranch.hog 4.1.0.0
%
16--> IX51366 Hogs producing eggs.
16--> IX81360 Piglets have too many ears.
]
}

Section des informations requises

La section des informations requises contient des informations sur les dépendances d'installation sur d'autres ensembles de fichiers ou mises à jour d'ensembles de fichiers. Chaque élément requis répertorié dans la section des éléments requis doit être satisfait conformément aux règles requises afin d'appliquer la mise à jour de l'ensemble de fichiers ou de l'ensemble de fichiers.

Avant toute installation ou mise à jour, la commande " installp compare l'état actuel des jeux de fichiers à installer avec les exigences énumérées dans le fichier " lpp_name. Si l'indicateur '-g a été spécifié avec la commande 'installp, tous les éléments manquants sont ajoutés à la liste des jeux de fichiers à installer. Les ensembles de fichiers sont commandés pour l'installation en fonction de tous les prérequis. Juste avant l'installation d'un jeu de fichiers, la commande " installp vérifie à nouveau les conditions requises pour ce jeu de fichiers. Cette vérification vérifie que tous les prérequis installés précédemment dans le processus d'installation ont été installés correctement et que tous les prérequis sont satisfaits.

Dans les descriptions suivantes des différents types de conditions requises, RequiredFilesetLevel représente le niveau minimum du jeu de fichiers qui satisfait aux conditions requises. Sauf en cas de blocage explicite pour les raisons décrites dans la section relative aux informations de remplacement, les nouveaux niveaux d'un ensemble de fichiers satisfont les conditions requises d'un niveau antérieur. Par exemple, une exigence concernant le jeu de fichiers " plum.tree 2.2.0.0 est satisfaite par le jeu de fichiers " plum.tree 3.1.0.0.

Prérequis

Un prérequis indique que l'ensemble de fichiers spécifié doit être installé au niveau de l'ensemble de fichiers spécifié ou à un niveau supérieur pour que l'installation de l'ensemble de fichiers en cours puisse aboutir. Si l'installation d'un jeu de fichiers prérequis est prévue, la commande " installp ordonne la liste des jeux de fichiers à installer pour s'assurer que le prérequis est respecté. Un prérequis sur un ensemble de fichiers dans le même package n'est pas garanti.

Syntaxe

*prereq Fileset RequiredFilesetLevel

Syntaxe alternative

Fileset RequiredFilesetLevel

Une mise à jour d'ensemble de fichiers contient un prérequis implicite pour son ensemble de fichiers de niveau de base. Si ce prérequis implicite n'est pas adéquat, vous devez spécifier explicitement un autre prérequis. La version et l' édition de la mise à jour et les prérequis implicites sont identiques. Si le FixLevel de la mise à jour est " 0, le ModificationLevel et le FixLevel du prérequis implicite sont tous deux " 0. Sinon, le prérequis implicite a un ModificationLevel identique au ModificationLevel la mise à jour et un FixLevel de " 0". Par exemple, une mise à jour de niveau 4.1.3.2 nécessite que son niveau 4.1.3.0 soit installé avant l'installation de la mise à jour. Une mise à jour de niveau 4.1.3.0 nécessite l'installation de son niveau 4.1.0.0 avant l'installation de la mise à jour.

Associée

Un élément corequis indique que l'ensemble de fichiers spécifié doit être installé pour que l'ensemble de fichiers en cours fonctionne correctement. À la fin du processus d'installation, la commande 'installp émet des messages d'avertissement pour les conditions préalables qui ne sont pas remplies. Un élément corequis peut être utilisé pour indiquer les éléments requis entre les ensembles de fichiers d'un même package.

Syntaxe

*coreq Fileset RequiredFilesetLevel

Si nécessaire

Une condition "if" indique que le jeu de fichiers spécifié ne doit se trouver au RequiredFilesetLevel que si le jeu de fichiers est installé au InstalledFilesetLevel. Il est généralement utilisé pour coordonner les dépendances entre les mises à jour des ensembles de fichiers. L'exemple suivant illustre une condition si requise:

*ifreq plum.tree (1.1.0.0) 1.1.2.3

Syntaxe

*ifreq Fileset [(InstalledFilesetLevel)] RequiredFilesetLevel

Si le jeu de fichiers " plum.tree n'est pas déjà installé, cet exemple n'entraîne pas son installation. Si le jeu de fichiers " plum.tree est déjà installé à l'un des niveaux suivants, cet exemple n'entraîne pas l'installation du niveau " 1.1.2.3:

1.1.2.3

Ce niveau correspond au RequiredFilesetLevel

1.2.0.0

Ce niveau est un niveau d'ensemble de fichiers de base différent.

1.1.3.0

Ce niveau remplace le RequiredFilesetLevel.

Si le jeu de fichiers " plum.tree est déjà installé à l'un des niveaux suivants, cet exemple entraîne l'installation du niveau " 1.1.2.3:

1.1.0.0

Ce niveau correspond au InstalledFilesetLevel.

1.1.2.0

Ce niveau est le même niveau de base que le InstalledFilesetLevel et un niveau inférieur au RequiredFilesetLevel.

Le paramètreInstalledFilesetLevel) est facultatif. S'il est omis, le " Version et le " Libération du " InstalledFilesetLevel et du " RequiredFilesetLevel sont supposés être les mêmes. Si le FixLevel du RequiredFilesetLevel est " 0, le ModificationLevel et le FixLevel du InstalledFilesetLevel sont tous deux " 0. Sinon, le InstalledFilesetLevel a un ModificationLevel identique au ModificationLevel du RequiredFilesetLevel et un FixLevel de " 0. Par exemple, si le RequiredFilesetLevel est " 4.1.1.1 et qu'aucun paramètre de InstalledFilesetLevel n'est fourni, le InstalledFilesetLevel est " 4.1.1.0. Si le RequiredFilesetLevel est " 4.1.1.0 et qu'aucun paramètre de InstalledFilesetLevel n'est fourni, le InstalledFilesetLevel est " 4.1.0.0.

Demande d'installation

Une condition d'installation indique que le jeu de fichiers spécifié ne doit être installé automatiquement que si le jeu de fichiers correspondant est déjà installé ou s'il figure sur la liste des jeux de fichiers à installer. Un prérequis installé est également installé si l'utilisateur demande explicitement qu'il soit installé. Une mise à jour d'un jeu de fichiers ne peut pas avoir de requis installé. Étant donné qu'un jeu de fichiers contenant les fichiers de messages d'un paquet particulier ne doit pas être installé automatiquement sans qu'une autre partie du paquet soit installée, un jeu de fichiers de messages doit toujours contenir une condition d'installation pour un autre jeu de fichiers de son produit.

Syntaxe

*instreq Fileset RequiredFilesetLevel

Groupe requis

Une condition requise de groupe indique que des conditions requises différentes peuvent satisfaire la condition requise. Un élément requis de groupe peut contenir des éléments prérequis, des éléments corequis, des éléments if-requis et des éléments requis de groupe imbriqués. Le nombre qui précède { RequisiteExpressionList } indique combien d'éléments de la RequisiteExpressionList sont nécessaires. Par exemple, " >2 indique qu'au moins trois éléments de la RequisiteExpressionList sont requis.

Syntaxe

>Number { RequisiteExpressionList }

Exemples de sections d'informations requises

1. L'exemple suivant illustre l'utilisation des éléments corequis. Le jeu de fichiers " book.create 12.30.0.0 ne peut fonctionner sans les jeux de fichiers " layout.text 1.1.0.0 et " index.generate 2.3.0.0 qui sont installés, de sorte que la section requise pour " book.create 12.30.0.0 contient :

   *coreq layout.text 1.1.0.0
   *coreq index.generate 2.3.0.0

   Le jeu de fichiers " index.generate 3.1.0.0 répond à la condition " index.generate car " 3.1.0.0 est un niveau plus récent que le niveau " 2.3.0.0 requis.
2. L'exemple suivant illustre l'utilisation des types de prérequis les plus courants. Le jeu de fichiers " new.fileset.rte 1.1.0.0 contient les éléments suivants :

   *prereq database.rte 1.2.0.0
   *coreq spreadsheet.rte 1.3.1.0
   *ifreq wordprocessorA.rte (4.1.0.0) 4.1.1.1
   *ifreq wordprocessorB.rte 4.1.1.1

   Le jeu de fichiers " database.rte doit être installé au niveau " 1.2.0.0 ou à un niveau supérieur avant que le jeu de fichiers " new.fileset.rte " puisse être installé. Si " database.rte et " new.fileset.rte sont installés au cours de la même session d'installation, le programme d'installation installe le jeu de fichiers " database avant le jeu de fichiers " new.fileset.rte.

   Le jeu de fichiers " spreadsheet.rte doit être installé au niveau " 1.3.1.0 ou à un niveau supérieur pour que le jeu de fichiers " new.fileset.rte " fonctionne correctement. Le jeu de fichiers " spreadsheet.rte n'a pas besoin d'être installé avant le jeu de fichiers " new.fileset.rte, à condition que les deux soient installés au cours de la même session d'installation. Si un niveau adéquat du jeu de fichiers " spreadsheet.rte n'est pas installé à la fin de la session d'installation, un message d'avertissement est émis, indiquant que la condition préalable n'est pas remplie.

   Si le jeu de fichiers " wordprocessorA.rte est installé (ou en cours d'installation avec " new.fileset.rte) au niveau " 4.1.0.0, la mise à jour du jeu de fichiers " wordprocessorA.rte doit être installée au niveau " 4.1.1.1 ou à un niveau supérieur.

   Si le jeu de fichiers " wordprocessorB.rte est installé (ou en cours d'installation avec " new.fileset.rte) au niveau " 4.1.1.0, la mise à jour du jeu de fichiers " wordprocessorB.rte doit être installée au niveau " 4.1.1.1 ou à un niveau supérieur.

3. L'exemple suivant illustre un prérequis installé. Le jeu de fichiers " Super.msg.fr_FR.Widget au niveau " 2.1.0.0 contient la condition d'installation suivante :

   *instreq Super.Widget 2.1.0.0

   Le jeu de fichiers " Super.msg.fr_FR.Widget ne peut pas être installé automatiquement lorsque le jeu de fichiers " Super.Widget n'est pas installé. Le jeu de fichiers " Super.msg.fr_FR.Widget peut être installé lorsque le jeu de fichiers " Super.Widget n'est pas installé si le jeu de fichiers figure explicitement dans la liste des jeux de fichiers à installer.

4. L'exemple suivant illustre un prérequis de groupe. Au moins l'un des jeux de fichiers prérequis listés doit être installé (les deux peuvent être installés). S'il est installé, le jeu de fichiers " spreadsheet_1.rte doit être au niveau " 1.2.0.0 ou supérieur ou le jeu de fichiers " spreadsheet_2.rte doit être au niveau " 1.3.0.0 ou supérieur.

   >0 {
   *prereq spreadsheet_1.rte 1.2.0.0
   *prereq spreadsheet_2.rte 1.3.0.0
   }

Informations sur la taille et l'accord de licence

La section des informations sur la taille et le contrat de licence contient des informations sur l'espace disque et les conditions de contrat de licence requises pour l'ensemble de fichiers.

informations sur la taille

Ces informations sont utilisées par le processus d'installation pour garantir que l'espace disque disponible est suffisant pour que l'installation ou la mise à jour aboutisse. Les informations de taille se présentent sous la forme suivante:

Directory PermanentSpace [TemporarySpace]

Le développeur du produit peut également spécifier " PAGESPACE ou " INSTWORK dans le champ du nom du chemin complet pour indiquer les besoins en espace disque pour l'espace de pagination et l'espace de travail nécessaires dans le répertoire du paquet pendant le processus d'installation.

Répertoire

Nom du chemin d'accès complet du répertoire dont la taille est requise.

PermanentSpace

Taille (en blocs de 512 octets) de l'espace permanent nécessaire à l'installation ou à la mise à jour. L'espace permanent est l'espace nécessaire une fois l'installation terminée. Cette zone a une signification différente dans les cas suivants:

Si le répertoire est " PAGESPACE, PermanentSpace représente la taille de l'espace de page nécessaire (en blocs de 512 octets) pour effectuer l'installation.

Si le répertoire est " INSTWORK, PermanentSpace représente le nombre de blocs de 512 octets nécessaires à l'extraction des fichiers de contrôle utilisés pendant l'installation. Ces fichiers de contrôle sont les fichiers qui sont archivés dans le fichier " liblpp.a.

TemporarySpace

Taille (en blocs de 512 octets) de l'espace temporaire nécessaire à l'installation uniquement. L'espace temporaire est libéré une fois l'installation terminée. La valeur TemporarySpace est facultative. Un exemple d'espace temporaire est l'espace nécessaire pour relier un fichier objet exécutable. Un autre exemple est l'espace nécessaire pour archiver un fichier objet dans une bibliothèque. Pour archiver dans une bibliothèque, la commande 'installp fait une copie de la bibliothèque, archive le fichier objet dans la bibliothèque copiée et déplace la bibliothèque copiée au-dessus de la bibliothèque d'origine. L'espace pour la copie de la bibliothèque est considéré comme un espace temporaire.

Lorsque le répertoire est " INSTWORK, TemporarySpace représente le nombre de blocs de 512 octets nécessaires pour le fichier " liblpp.a non extrait.

L'exemple suivant illustre une section d'informations de taille:

/usr/bin          30
/lib              40  20
PAGESPACE         10
INSTWORK          10    6

Comme il est difficile de prévoir comment les systèmes de fichiers sur disque sont montés dans l'arborescence, les entrées du nom du chemin d'accès au répertoire dans la section des informations sur la taille doivent être aussi précises que possible. Par exemple, il est préférable d'avoir une entrée pour " /usr/bin et une autre pour " /usr/lib que d'avoir une entrée combinée pour " /usr parce que " /usr/bin et " /usr/lib peuvent exister sur des systèmes de fichiers différents qui sont tous deux montés sous " /usr. En général, il est préférable d'inclure des entrées pour chaque répertoire dans lequel les fichiers sont installés.

Pour un paquet de mise à jour uniquement, les informations relatives à la taille doivent inclure tous les anciens fichiers (à remplacer) qui seront déplacés dans les répertoires " save. Ces anciens fichiers sont restaurés si la mise à jour est rejetée ultérieurement. Pour indiquer ces exigences de taille, un package de mise à jour doit spécifier les répertoires spéciaux suivants:

/usr/lpp/SAVESPACE

Le répertoire 'save pour les fichiers de pièces 'usr Par défaut, les fichiers de pièces " usr sont enregistrés dans le répertoire " /usr/lpp/PackageName/FilesetName/FilesetLevel.save

/lpp/SAVESPACE

Le répertoire 'save pour les fichiers de pièces 'root Par défaut, les fichiers de pièces " root sont enregistrés dans le répertoire " /lpp/PackageName/FilesetName/FilesetLevel.save

Informations sur l'accord de licence

Un ajout récent au processus d'installation d'AIX permet aux propriétaires de produits d'exiger qu'un client signe un accord de licence avant l'installation du produit. La commande 'installp lit le fichier lpp_name d'un jeu de fichiers comme d'habitude pour n'importe quelle image. S'il existe des entrées " LAF ou " LAR dans la section "size" du fichier lpp_name, la commande " installp appelle la commande " inulag qui affiche la licence dans une fenêtre et enregistre l'acceptation de la licence par le client. Si le client refuse d'accepter la licence, l'installation de ce produit est interrompue.

Où placer le fichier de licence

Le placement des fichiers de licence incombe au propriétaire du produit. Toutefois, il est suggéré que la licence soit placée dans le " /usr/swlag/LANG. Le nom suggéré pour le fichier de l'accord de licence est " ProductName_VersionRelease.la. Il n'est pas nécessaire d'utiliser ce nom ou cet emplacement. La commande " installp et cet emballage fournissent simplement une méthode pour transmettre l'information aux clients. Tous les outils et le contenu des fichiers doivent être fournis par le produit.

Exigences de traduction pour le fichier de licence

Si les fichiers de l'accord de licence doivent être traduits dans les langues prises en charge, il est recommandé de séparer les fichiers par langue. Cette traduction peut nécessiter la création de plusieurs fichiers.

Comment envoyer le fichier de licence

Un produit peut expédier le fichier de licence dans le cadre de son produit principal ou dans un ensemble de fichiers distinct pour le produit. De nombreux produits choisissent de créer un ensemble de fichiers distinct pour l'expédition uniquement des fichiers de licence. Cela permet à un produit comportant de nombreuses fonctionnalités différentes de créer un fichier de licence et un jeu de fichiers qui peuvent être expédiés sur tous les supports requis pour chaque fonctionnalité, au lieu d'avoir à inclure les fichiers dans plusieurs fonctionnalités différentes. Les suggestions actuelles pour le nom de l'ensemble de fichiers sont lpp.license ou lpp.loc.license. La plupart des produits utilisent actuellement la première suggestion. Si vous souhaitez que l'ensemble de fichiers de licence soit masqué pour le client dans les installations standard, utilisez lpp.loc.license car l'ensemble de fichiers de licence n'a pas besoin d'être sélectionné pour l'installation.

Comment empaqueter le fichier de licence

Le fichier lui-même n'est jamais répertorié dans les fichiers " fileset.al ou " fileset.inventory du jeu de fichiers. La commande 'installp trouve la licence grâce à l'entrée dans la section taille du fichier ProductName Les types d'entrée sont les suivants:

LAF

Le fichier d'accord de licence (LAF) indique à la commande " installp que ce fichier de licence particulier est fourni avec ce jeu de fichiers.

Les fichiers de contrat de licence sont indiqués par une entrée de section de taille avec:

LAF<lang>license_file size

LAF

Stands for license Agreement File (fichier d'accord de licence)

< lang>

Langue dans laquelle le fichier est traduit. Il s'agit généralement d'entrées telles que en_US, fr_FR, Ja_JP et zh_TW. Si <lang> n'est pas spécifié, le fichier de contrat est considéré comme non traduit et codé en ASCII. Si le fichier de l'accord de licence est traduit, " <lang> doit faire partie du chemin d'accès afin que l'entrée de l'exigence puisse être associée au fichier.

license_file

Chemin d'accès complet au fichier de licence tel qu'il est créé dans l'image et placé sur le système. Le chemin suggéré se présente sous la forme /usr/swlag/en_US/ProductName_VersionRelease.la

taille

Il s'agit de la taille réelle du fichier de licence, en blocs de 512 octets, afin de s'assurer que " installp dispose de suffisamment d'espace pour placer le fichier de licence sur le système.

LAR

La condition relative au contrat de licence indique à la commande 'installp que ce jeu de fichiers nécessite l'installation du fichier de contrat de licence indiqué. Ce n'est pas la même chose qu'un prérequis car il se trouve dans le fichier et non dans un ensemble de fichiers. Les fichiers et les ensembles de fichiers ont des formats et des objectifs différents. Il ne faut pas les confondre.

LAR

Stands for license Agreement Requisite

fichier_licence_demande

Chemin d'accès complet au fichier de licence requis pour installer cet ensemble de fichiers. En règle générale, ces entrées utilisent %L dans le chemin au lieu du nom de langue réel pour permettre l'affichage du fichier approprié sans forcer le client à afficher toutes les langues.

En général, un seul jeu de fichiers contient les fichiers et toutes les entrées LAF. Les autres jeux de fichiers du produit qui requièrent cette licence ne sont livrés qu'avec l'entrée LAR. Le jeu de fichiers qui contient les entrées LAF contient également les fichiers dont le chemin d'accès complet est indiqué dans l'image BFF, mais ces fichiers ne sont pas répertoriés dans les fichiers " fileset.al " ou " fileset.inventory du jeu de fichiers. Le modèle utilisé pour les licences électroniques exige que les fichiers soient enregistrés auprès de la SWVPD pas La commande " installp:

1. Recherche une exigence dans le fichier.
2. Vérifie dans le système si la demande a été acceptée.
3. Si le fichier n'a pas été accepté
   1. Recherche l'ensemble de fichiers qui expédie le fichier.
   2. Extrait (restaure) uniquement ce fichier de l'image BFF.
   3. Affichez le fichier pour le client.

Exemple de jeu de fichiers LAF

Voici un exemple d'ensemble de fichiers qui fournit le fichier de licence:

iced.tea.loc.license 03.01.0000.0000 1 N U en_US IcedTea Recipe License Information
[
%
INSTWORK 16 160
LAF/usr/swlag/de_DE/iced.tea.la 24
LAF/usr/swlag/DE_DE/iced.tea.la 24
LAF/usr/swlag/en_US/iced.tea.la 24
LAF/usr/swlag/EN_US/iced.tea.la 24
LAF/usr/swlag/es_ES/iced.tea.la 24
LAF/usr/swlag/ES_ES/iced.tea.la 24
LAF/usr/swlag/fr_FR/iced.tea.la 24
LAF/usr/swlag/FR_FR/iced.tea.la 24
LAF/usr/swlag/it_IT/iced.tea.la 24
LAF/usr/swlag/IT_IT/iced.tea.la 24
LAF/usr/swlag/ja_JP/iced.tea.la 24
LAF/usr/swlag/JA_JP/iced.tea.la 32
LAF/usr/swlag/Ja_JP/iced.tea.la 24
LAF/usr/swlag/ko_KR/iced.tea.la 24
LAF/usr/swlag/KO_KR/iced.tea.la 24
LAF/usr/swlag/pt_BR/iced.tea.la 24
LAF/usr/swlag/PT_BR/iced.tea.la 24
LAF/usr/swlag/ru_RU/iced.tea.la 24
LAF/usr/swlag/RU_RU/iced.tea.la 48
LAF/usr/swlag/zh_CN/iced.tea.la 16
LAF/usr/swlag/zh_TW/iced.tea.la 16
LAF/usr/swlag/Zh_TW/iced.tea.la 16
LAF/usr/swlag/ZH_TW/iced.tea.la 24
%
%
%
]

Exemple de jeu de fichiers LAR

Voici un exemple de jeu de fichiers qui transfère la licence requise au fichier de licence :

iced.tea.server 03.01.0000.0010 1 N B en_US Iced Tea Recipe Group
[
*prereq bos.net.tcp.client 5.1.0.10
*coreq iced.tea.tools 5.1.0.10
*coreq Java14.sdk 1.4.0.1
%
/usr/bin 624
/usr/lib/objrepos 24
/usr/include 16
/usr/include/sys 56
/usr/lpp/iced.tea 22
/usr/samples/iced.tea 8
/usr/samples/iced.tea/server 504
/usr/lpp/iced.tea/inst_root/etc/tea 8
/usr/iced.tea 8
/usr/lpp/iced.tea/inst_root/etc/tea/Top 8
INSTWORK 208 96
/lpp/iced.tea 104
/etc/tea 8
/etc/objrepos 8
/etc/tea/Top 8
/tmp 0 6
LAR/usr/swlag/%L/iced.tea.la 0
%
%
%
]

Remplacer la section d'information

La section des informations de remplacement indique les niveaux d'un jeu de fichiers ou d'une mise à jour de jeu de fichiers pour lesquels ce jeu de fichiers ou cette mise à jour de jeu de fichiers peut (ou ne peut pas) être utilisé en remplacement. Les informations de remplacement sont facultatives et s'appliquent uniquement aux modules d'installation de base d'ensemble de fichiers formatés AIX 4.1et aux modules de mise à jour d'ensemble de fichiers formatés AIX 3.2.

Un jeu de fichiers plus récent remplace toute version plus ancienne de ce jeu de fichiers, sauf si la section supersedes du fichier " lpp_name identifie le dernier niveau du jeu de fichiers qu'il remplace. Dans les rares cas où un jeu de fichiers ne remplace pas tous les niveaux antérieurs de ce jeu de fichiers, la commande " installp n'utilise pas le jeu de fichiers pour satisfaire aux exigences des niveaux antérieurs au niveau du jeu de fichiers qui figure dans la section "supersedes".

Une mise à jour d'ensemble de fichiers remplace une mise à jour antérieure pour cet ensemble de fichiers uniquement si elle contient tous les fichiers, le traitement de la configuration et les informations requises contenues dans l'ancienne mise à jour d'ensemble de fichiers. La commande 'installp détermine qu'une mise à jour d'un jeu de fichiers remplace une autre mise à jour pour ce jeu de fichiers dans les conditions suivantes :

• Les niveaux de version, d'édition et de modification des mises à jour sont identiques, les niveaux de correction sont tous deux non nuls et la mise à jour ayant le niveau de correction le plus élevé ne contient pas de condition préalable à un niveau du jeu de fichiers supérieur ou égal au niveau de la mise à jour ayant le niveau de correction le moins élevé.
• Les niveaux de version et d'édition des mises à jour sont identiques et la mise à jour ayant le niveau de modification le plus élevé ne contient pas de condition préalable à un niveau du jeu de fichiers supérieur ou égal au niveau de la mise à jour ayant le niveau de modification le plus élevé.

Par exemple, la mise à jour de l'ensemble de fichiers " farm.apps.hog 4.1.0.1 entraîne la mise à jour de " /usr/sbin/sellhog. La mise à jour du jeu de fichiers " farm.apps.hog 4.1.0.3 permet de mettre à jour le fichier " /usr/sbin/sellhog et le fichier " /etc/hog. La mise à jour du jeu de fichiers " farm.apps.hog 4.1.1.2 permet de mettre à jour le fichier " /usr/bin/raisehog.

La mise à jour " farm.apps.hog 4.1.0.3 remplace " farm.apps.hog 4.1.0.1 parce qu'elle fournit les mêmes fichiers et s'applique au même niveau " farm.apps.hog 4.1.0.0.

La mise à jour " farm.apps.hog 4.1.1.2 ne remplace ni " farm.apps.hog 4.1.0.3 ni " farm.apps.hog 4.1.0.1 car elle ne contient pas les mêmes fichiers et s'applique à un niveau différent, " farm.apps.hog 4.1.1.0. La mise à jour " farm.apps.hog 4.1.1.0 remplacefarm.apps.hog 4.1.0.1 et " farm.apps.hog 4.1.0.3.

Remplacer la section relative aux niveaux d'installation des jeux de fichiers (niveaux de base)

Un package d'installation d'ensemble de fichiers au format AIX 4.1peut contenir les entrées de remplacement suivantes:

Entrée de barrière

Identifie le niveau de l'ensemble de fichiers dans lequel une incompatibilité majeure a été introduite. Une telle incompatibilité empêche l'ensemble de fichiers en cours de satisfaire les conditions requises à des niveaux de l'ensemble de fichiers antérieurs au niveau spécifié.

Entrée de compatibilité

Indique que le jeu de données peut être utilisé pour satisfaire aux exigences d'un autre jeu de données. Une entrée de compatibilité est utilisée lorsqu'un ensemble de fichiers a été renommé ou rendu obsolète. Un seul ensemble de fichiers peut remplacer un ensemble de fichiers donné. Vous ne pouvez spécifier qu'une seule entrée de compatibilité pour chaque ensemble de fichiers.

Le fichier " lpp_name peut contenir au maximum une barrière et une entrée de compatibilité pour un jeu de fichiers.

Une entrée de barrière se compose du nom de l'ensemble de fichiers et du niveau de l'ensemble de fichiers lors de l'introduction de l'incompatibilité. Une barrière d'entrée n'est nécessaire pour un ensemble de fichiers que dans les rares cas où un niveau de l'ensemble de fichiers a introduit une incompatibilité telle que les fonctions requises par les ensembles de fichiers dépendants ont été modifiées ou supprimées à un point tel que les exigences des niveaux précédents de l'ensemble de fichiers ne sont pas satisfaites. Une entrée de barrière doit exister dans toutes les versions suivantes de l'ensemble de fichiers, indiquant le niveau le plus récent de l'ensemble de fichiers qui satisfait les conditions requises par les ensembles de fichiers dépendants.

Par exemple, si une incompatibilité majeure a été introduite dans le jeu de fichiers " Bad.Idea 6.5.6.0, la section des informations de remplacement pour chaque paquet d'installation du jeu de fichiers " Bad.Idea à partir du niveau " 6.5.6.0 contiendra une entrée de barrière " Bad.Idea 6.5.6.0 Cette barrière à l'entrée empêcherait qu'une exigence du " Bad.Idea 6.5.4.0 soit satisfaite par tout niveau de " Bad.Idea supérieur ou égal au " 6.5.6.0.

Une entrée de compatibilité se compose d'un nom d'ensemble de fichiers (différent de l'ensemble de fichiers du module) et d'un niveau d'ensemble de fichiers. Le niveau d'ensemble de fichiers identifie le niveau auquel les conditions requises pour l'ensemble de fichiers spécifié (et les niveaux antérieurs de cet ensemble de fichiers) sont satisfaites par l'ensemble de fichiers du module d'installation. La compatibilité est utile lorsque l'ensemble de fichiers spécifié est obsolète ou a été renommé et que la fonction de l'ensemble de fichiers spécifié est contenue dans l'ensemble de fichiers en cours. Le niveau du jeu de fichiers dans l'entrée de compatibilité doit être supérieur à tout niveau attendu pour le jeu de fichiers spécifié.

Supposons par exemple que l'ensemble de fichiers " Year.Full " 19.91.0.0 ne soit plus livré en tant qu'unité, mais qu'il soit divisé en plusieurs ensembles de fichiers individuels plus petits. Un seul des petits ensembles de fichiers résultants, par exemple " Winter 19.94.0.0, doit contenir une entrée de compatibilité " Year.Full 19.94.0.0. Cette entrée de compatibilité permet au jeu de fichiers " Winter 19.94.0.0 de satisfaire aux exigences des jeux de fichiers dépendant de " Year.Full aux niveaux " 19.94.0.0 et antérieurs.

Remplace la transformation

La commande " installp permet d'installer des jeux de fichiers et des mises à jour de jeux de fichiers qui remplacent d'autres jeux de fichiers ou mises à jour de jeux de fichiers :

• Si le support d'installation ne contient pas d'ensemble de fichiers ou de mise à jour d'ensemble de fichiers que l'utilisateur a demandé d'installer, une mise à jour d'ensemble de fichiers ou d'ensemble de fichiers de remplacement peut être installée sur le support d'installation.

  Par exemple, supposons qu'un utilisateur invoque la commande " installp avec l'option " -g (installation automatique des requis) pour installer le jeu de fichiers " farm.apps.hog 4.1.0.2. Si le support d'installation ne contient que le jeu de fichiers " farm.apps.hog 4.1.0.4, la commande " installp installe le jeu de fichiers " farm.apps.hog 4.1.0.4 parce qu'il est supérieur au niveau demandé.

• Si le système et le support d'installation ne contiennent pas d'ensemble de fichiers ou de mise à jour d'ensemble de fichiers requis, celui-ci peut être satisfait par une mise à jour d'ensemble de fichiers ou d'ensemble de fichiers de remplacement.
• Si une mise à jour est demandée pour l'installation et que l'indicateur " -g est spécifié, la demande est satisfaite par la mise à jour la plus récente sur le support d'installation.

  Lorsque l'indicateur '-g est spécifié avec la commande 'installp, toute mise à jour demandée pour l'installation (explicitement ou implicitement) est satisfaite par la mise à jour la plus récente sur le support d'installation. Si l'utilisateur souhaite installer un niveau particulier d'une mise à jour, pas nécessairement le dernier niveau, il peut invoquer la commandeinstallp sans l'indicateur " -g

• Si une mise à jour et une mise à jour ultérieure (toutes deux sur le support d'installation) sont demandées pour installation, la commande " installp n'installe que la mise à jour la plus récente.

  Dans ce cas, si un utilisateur souhaite appliquer une certaine mise à jour et la mise à jour qui la remplace à partir du support d'installation, il doit effectuer des opérations " installp distinctes pour chaque niveau de mise à jour. Cette opération n'a pas de sens si les deux mises à jour sont appliquées et validées (-ac). La validation de la deuxième mise à jour supprime la première mise à jour du système.

Correction de la section d'information

La section relative aux informations sur les correctifs est facultative. Les entrées de la section Informations sur les correctifs contiennent un mot clé de correction et une description de 60 caractères ou moins de l'incident corrigé. Un mot clé de correction est un identificateur de 16 caractères ou moins correspondant au correctif. Les mots-clés fixes commençant par 'ix, 'iy, 'IY et 'IX sont réservés à l'usage du fabricant du système d'exploitation.

Un niveau de technologie est un correctif qui est un niveau de mise à jour majeur. Les kits de maintenance préventive périodiques sont des niveaux technologiques. Un identificateur de niveau technologique commence par le nom du produit logiciel (et non de l'ensemble), suivi d'un point (.) et d'un niveau d'identification, tel que " farm.4.1.1.0.

Le fichier de la bibliothèque de contrôle de l'installation liblpp.a

Le fichier 'liblpp.a est un fichier d'archive qui contient les fichiers nécessaires pour contrôler l'installation du paquet. Vous pouvez créer un fichier 'liblpp.a pour votre paquet en utilisant la commande 'ar avec l'option '-g sur les systèmes postérieurs à AIX 4.3 pour garantir la création d'une archive 32 bits. Cette section décrit la plupart des fichiers que vous pouvez placer dans une archive " liblpp.a

Dans cette section, Ensemble de fichiers apparaît dans les noms des fichiers de contrôle. Fileset représente le nom de l'ensemble de fichiers distinct à installer dans le progiciel. Par exemple, supposons que le fichier de liste d'application soit décrit comme " Fileset.al. Le fichier de liste d'application pour l'option " bos.net.tcp.client du produit logiciel " bos.net serait alors " bos.net.tcp.client.al.

De nombreux fichiers décrits dans cette section sont facultatifs. Un fichier facultatif n'est nécessaire que si la fonction fournie par le fichier est requise pour la mise à jour de l'ensemble de fichiers ou de l'ensemble de fichiers. Sauf indication contraire, un fichier appartient à la fois aux packages d'installation complète et aux packages de mise à jour de l'ensemble de fichiers.

Fichiers de données contenus dans le fichier " liblpp.a

Fileset.al

Liste d'application. Ce fichier répertorie tous les fichiers à restaurer pour cet ensemble de fichiers. Les fichiers sont listés un par ligne avec un chemin relatif à la racine, comme dans " ./usr/bin/pickle. Un fichier de liste d'application est nécessaire si des fichiers sont livrés avec le jeu de fichiers ou la mise à jour du jeu de fichiers.

Fileset.cfginfo

Fichier d'instructions spéciales. Ce fichier répertorie un mot clé par ligne, chaque mot clé indiquant les caractéristiques spéciales de l'ensemble de fichiers ou de la mise à jour de l'ensemble de fichiers. Le seul mot-clé actuellement reconnu est BOOT, qui génère un message à la fin de l'installation indiquant que le système doit être redémarré.

Fileset.cfgfiles

Liste des fichiers configurables par l'utilisateur et des instructions de traitement à utiliser lors de l'application d'un niveau d'installation plus récent ou égal d'un ensemble de fichiers déjà installé. Avant de restaurer les fichiers énumérés dans le fichier " Fileset.al, le système enregistre les fichiers énumérés dans le fichier " Fileset.cfgfiles Par la suite, ces fichiers sauvegardés sont traités selon les méthodes de traitement spécifiées dans le fichier " Fileset.cfgfiles ".

Fileset.copyright

Fichier d'informations de copyright requis pour l'ensemble de fichiers. Ce fichier se compose du nom complet du produit logiciel suivi des mentions de copyright.

Fileset.err

Fichier de modèle d'erreur utilisé en entrée de la commande " errupdate pour ajouter ou supprimer des entrées dans le référentiel de modèles d'enregistrements d'erreurs. Ce fichier est couramment utilisé par les logiciels de support de périphérique. La commande " errupdate crée un fichier " Fileset.undo.err à des fins de nettoyage. Voir la commande " errupdate pour des informations sur le format du fichier " Fileset.err. Ce fichier ne peut être inclus que dans la partie racine d'un ensemble de fichiers.

Fileset.fixdata

Fichier de format de section. Ce fichier contient des informations sur les correctifs contenus dans un jeu de fichiers ou une mise à jour de jeu de fichiers.

Fileset.inventory

Fichier d'inventaire. Ce fichier contient les données techniques essentielles requises pour les fichiers de l'ensemble de fichiers ou de la mise à jour de l'ensemble de fichiers. Le fichier d'inventaire est un fichier au format stanza contenant une entrée pour chaque fichier à installer ou à mettre à jour.

Fileset.namelist

Liste des ensembles de fichiers obsolètes et de l'ensemble de fichiers en cours (le cas échéant) qui contenaient autrefois des fichiers existants dans l'ensemble de fichiers à installer. Ce fichier est utilisé uniquement pour l'installation de produits logiciels reconditionnés.

Fileset.odmadd ou Fileset.*.odmadd

Strophes à ajouter aux bases de données ODM (Object Data Manager).

Fileset.rm_inv

Supprimez le fichier d'inventaire. Ce fichier est destiné à l'installation de produits logiciels reconditionnés uniquement et doit exister si l'ensemble de fichiers n'est pas un remplacement direct d'un ensemble de fichiers obsolète. Ce fichier au format stanza contient les noms des fichiers qui doivent être supprimés des ensembles de fichiers obsolètes.

Fileset.size

Ce fichier contient l'espace requis pour les fichiers inclus dans cet ensemble de fichiers, comme décrit précédemment dans cette section.

Fileset.trc

Fichier modèle de rapport de trace. La commande " trcupdate utilise ce fichier pour ajouter, remplacer ou supprimer des entrées de rapport de traçage dans le fichier " /etc/trcfmt. La commande " trcupdate crée un fichier " Fileset.undo.trc à des fins de nettoyage. Seule la partie " root d'un paquet peut contenir des fichiers " Fileset.trc.

lpp.acf

Fichier de contrôle d'archivage pour l'ensemble du package. Ce fichier n'est nécessaire que lors de l'ajout ou du remplacement d'un fichier membre d'une archive dans un fichier d'archive existant sur le système. Le fichier de contrôle des archives se compose de lignes contenant des paires de fichiers membres dans le répertoire temporaire, comme indiqué dans le fichier " Fileset.al, et le fichier d'archives auquel le membre appartient, tous deux répertoriés par rapport à " root ", comme dans :

./usr/ccs/lib/libc/member.o ./usr/ccs/lib/libc.a

lpp.README

Fichier Readme. Ce fichier contient des informations que l'utilisateur doit lire avant d'utiliser le logiciel. Ce fichier est facultatif et peut également être nommé " README, " lpp.doc, " lpp.instr ou " lpp.lps.

productid

Fichier d'identification du produit. Ce fichier se compose d'une seule ligne indiquant le nom du produit, l'identificateur du produit (limite de 20 caractères) et le numéro de dispositif facultatif (limite de 10 caractères).

Fichiers exécutables facultatifs contenus dans le fichier " liblpp.a

Les fichiers exécutables spécifiques au produit qui sont décrits dans cette section sont appelés au cours du processus d'installation. Sauf indication contraire, les noms de fichiers se terminant par " _i sont utilisés lors de l'installation uniquement, et les noms de fichiers se terminant par " _u sont utilisés lors de la mise à jour du jeu de fichiers uniquement. Tous les fichiers décrits dans cette section sont facultatifs et peuvent être des scripts shell ou des modules d'objets exécutables. Chaque programme doit avoir une valeur de retour de 0 (zéro), sauf si le programme est destiné à faire échouer l'installation ou la mise à jour.

Fileset.config ou Fileset.config_u

Modifie la configuration vers la fin du processus d'installation ou de mise à jour par défaut. le Fileset.config n'est utilisé que lors de la procédure d'installation.

Fileset.odmdel ou Fileset.*.odmdel

Met à jour les informations de la base de données ODM pour le jeu de fichiers avant d'ajouter de nouvelles entrées ODM pour le jeu de fichiers. Les conventions de dénomination des fichiers " odmdel permettent à un jeu de fichiers d'avoir plusieurs fichiers " odmdel

Fileset.pre_d

Indique si un jeu de fichiers peut être supprimé lors de la désinstallation. Le programme doit renvoyer la valeur 0 (zéro) si l'ensemble de fichiers peut être supprimé. Les ensembles de fichiers sont amovibles par défaut. Le programme doit générer des messages d'erreur indiquant pourquoi le jeu de fichiers n'est pas amovible.

Fileset.pre_i ou Fileset.pre_u

S'exécute avant de restaurer ou d'enregistrer les fichiers de la liste d'application dans le paquet, mais après avoir supprimé les fichiers d'une version précédemment installée du jeu de fichiers.

Fileset.pre_rej

S'exécute avant l'opération de rejet ou avant l'aperçu d'une opération de rejet du jeu de données. Utilisez le script pour déterminer si l'ensemble de fichiers peut être rejeté. N'utilisez pas ce script pour exécuter des commandes qui modifient quoi que ce soit sur le système. Si le script se termine avec un code de retour non nul, l'opération de rejet n'est pas autorisée.

Fileset.pre_rm

S'exécute pendant l'installation d'un jeu de fichiers avant de supprimer les fichiers d'une version précédente du jeu de fichiers.

Fileset.post_i ou Fileset.post_u

S'exécute après la restauration des fichiers à partir de la liste d'application de l'installation ou de la mise à jour de l'ensemble de fichiers.

Fileset.unconfig ou Fileset.unconfig_u

Annule le traitement de la configuration effectué lors de l'installation ou de la mise à jour au cours d'une désinstallation ou d'un rejet d'un jeu de fichiers. le Fileset.unconfig est utilisé uniquement lors de la désinstallation.

Fileset.unodmadd

Supprime les entrées qui ont été ajoutées aux bases de données ODM lors de l'installation ou de la mise à jour.

Fileset.unpost_i ou Fileset.unpost_u

Annule le traitement effectué suite à la restauration des fichiers de la liste d'application dans l'installation ou la mise à jour lors d'une désinstallation ou d'un rejet d'un jeu de fichiers.

Fileset.unpre_i ou Fileset.unpre_u

Annule le traitement effectué avant de restaurer les fichiers de la liste d'application dans l'installation ou la mise à jour lors d'une désinstallation ou d'un rejet d'un jeu de fichiers.

Si l'un de ces fichiers exécutables exécute une commande susceptible de modifier la configuration des périphériques sur une machine, ce fichier exécutable doit vérifier la variable d'environnement INUCLIENTS avant d'exécuter la commande. Si la variable d'environnement INUCLIENTS est définie, la commande ne doit pas être exécutée. L'environnement de gestion des installations en réseau (NIM) utilise la commande " installp à de nombreuses fins, dont certaines requièrent la commande " installp pour contourner une partie de son traitement normal. NIM définit la variable d'environnement INUCLIENTS lorsque ce traitement normal doit être ignoré.

Si le processus d'installation par défaut est insuffisant pour votre paquet, vous pouvez fournir les fichiers exécutables suivants dans le fichier 'liblpp.a Si ces fichiers sont fournis dans votre paquetage, la commande 'installp utilise les fichiers fournis par votre paquetage à la place des fichiers par défaut du système. Les fichiers fournis par le progiciel doivent contenir les mêmes fonctions que les fichiers par défaut, faute de quoi des résultats inattendus peuvent se produire. Vous pouvez utiliser les fichiers par défaut comme modèles pour créer vos propres fichiers. Il est recommandé d'utiliser les fichiers par défaut au lieu des fichiers fournis par le paquet.

instal

Utilisé à la place du script d'installation par défaut " /usr/lib/instl/instal. La commande " installp appelle ce fichier exécutable si un jeu de fichiers d'un paquet d'installation est appliqué.

lpp.cleanup

Utilisé à la place du script de nettoyage de l'installation par défaut " /usr/lib/instl/cleanup. La commande " installp appelle ce fichier exécutable si un jeu de fichiers dans un paquet d'installation ou de mise à jour a été partiellement appliqué et doit être nettoyé pour remettre le jeu de fichiers dans un état cohérent.

lpp.deinstal

Utilisé à la place du script de suppression du jeu de fichiers par défaut " /usr/lib/instl/deinstal. Ce fichier exécutable doit être placé dans le répertoire " /usr/lpp/PackageName. La commande 'installp appelle ce fichier exécutable si un jeu de fichiers d'un paquet d'installation est supprimé.

lpp.reject

Utilisé à la place du script de rejet d'installation par défaut " /usr/lib/instl/reject. La commande 'installp appelle cet exécutable si la mise à jour d'un jeu de fichiers dans un paquet de mise à jour est rejetée. (Le script " /usr/lib/instl/reject par défaut est un lien vers le script " /usr/lib/instl/cleanup )

update

Utilisé à la place du script de mise à jour du jeu de fichiers par défaut " /usr/lib/instl/update. La commande " installp appelle ce fichier exécutable si un jeu de fichiers d'un paquet de mise à jour est appliqué. (Le script " /usr/lib/instl/update par défaut est un lien vers le script " /usr/lib/instl/instal )

Pour assurer la compatibilité avec la commande " installp, l'exécutable " instal ou de mise à jour fourni avec un logiciel doit :

• Traiter tous les ensembles de fichiers du progiciel. Il peut traiter l'installation de tous les ensembles de fichiers ou appeler d'autres exécutables pour chaque ensemble de fichiers.
• Utilisez la commande " inusave pour enregistrer le niveau actuel des fichiers à installer.
• Utilisez la commande 'inurest pour restaurer tous les fichiers nécessaires à la partie 'usr à partir du support de distribution.
• Utilisez la commande " inucp pour copier tous les fichiers nécessaires à la partie " root à partir du répertoire " /usr/lpp/Package_Name/inst_root.
• Créer un fichier " $INUTEMPDIR/status indiquant le succès ou l'échec pour chaque jeu de fichiers en cours d'installation ou de mise à jour.
• Renvoie un code de sortie indiquant le statut de l'installation. Si le fichier exécutable 'instal ou 'update renvoie un code de retour non nul et qu'aucun fichier 'status n'est trouvé, la procédure d'installation suppose que tous les jeux de fichiers ont échoué.

Fichier exécutable facultatif contenu dans le fichier " Fileset.al

Fileset.unconfig_d

Annule les opérations de configuration spécifiques au jeu de données effectuées lors de l'installation et des mises à jour du jeu de données. Le fichier " Fileset.unconfig_d est utilisé lorsque l'indicateur " -u est spécifié avec la commande " installp. Si ce fichier n'est pas fourni et que l'indicateur '-u est spécifié, les opérations 'Fileset.unconfig, 'Fileset.unpost_i et 'Fileset.unpre_i sont effectuées.

Description détaillée des fichiers de contrôle de l'installation

Fichiers de contrôle d'installation spécifiques aux produits reconditionnés

La base de données d'informations sur les logiciels est consultée pour déterminer si l'un ou l'autre des jeux de fichiers répertoriés dans le fichier " Fileset.namelist (s'il existe) est déjà installé sur le système. Si c'est le cas, le jeu de fichiers et le niveau d'installation sont inscrits dans le fichier " Fileset.installed_list.

Le fichier " Fileset.installed_list contient une entrée d'une ligne pour chaque jeu de fichiers installé. Chaque entrée contient le nom de l'ensemble de fichiers et le niveau de l'ensemble de fichiers.

storm.rain 1.1.0.0

Pelly.com
GooseCreek.rte
CedarBayou.stream 

Pelly.obj 1.2.3.0
CedarBayou.stream 4.1.3.2

Le fichier " Fileset.namelist doit être fourni dans le fichier " usr ou dans la partie racine du fichier " liblpp.a ". Le fichier " Fileset.namelist n'est valable que pour les paquets d'installation ; il n'est pas valable pour les paquets de mise à jour.

Au début de l'installation, la commande " installp consulte les données vitales du produit logiciel (SWVPD) pour déterminer si le jeu de fichiers ou tout autre jeu de fichiers répertorié dans le fichier " Fileset.namelist est déjà installé sur le système. La commande " installp écrit dans le fichier " Fileset.installed_list les noms et les niveaux des jeux de fichiers installés, mettant ces informations à la disposition des exécutables fournis par le produit.

family.business

lawoffice.mgr

lawoffice.mgr
BusinessOffice.mgr

Si le fichier " Fileset.namelist ne contient qu'une seule entrée et que l'ensemble de fichiers actuel ne remplace pas directement l'ensemble de fichiers figurant dans le fichier " Fileset.namelist, vous devez inclure un fichier " Fileset.rm_inv dans le fichier " liblpp.a ". La procédure d'installation utilise les fichiers " Fileset.namelist et " Fileset.rm_inv pour déterminer si un jeu de fichiers est un remplacement direct d'un autre jeu de fichiers. Si le fichier " Fileset.namelist ne contient qu'une seule entrée et qu'il n'y a pas de fichier " Fileset.rm_inv, la procédure d'installation suppose que le nouveau jeu de fichiers remplace directement l'ancien. Lorsque le nouveau jeu de fichiers (de remplacement) est installé, la procédure d'installation supprime du système tous les fichiers de l'ancien jeu de fichiers (remplacé), même les fichiers qui ne sont pas inclus dans le nouveau jeu de fichiers.

Dans les exemples précédents, le jeu de fichiers " small.business remplace directement le jeu de fichiers " family.business, de sorte que le fichier " small.business.rm_inv ne doit pas exister. Le jeu de fichiers " LawPractice.client ne remplace pas directement le jeu de fichiers " lawoffice.mgr, de sorte qu'un fichier " LawPractice.client.rm_inv doit exister, même s'il est vide.

Exemple

Les ensembles de fichiers bagel.shop.rte et bread.shop.rte sont expédiés séparément depuis des années. A présent, bagel.shop.rte est sur le point d'être livré avec bread.shop.rte. Pour cela, le fichier bread.shop.rte.namelist se présente comme suit:

bread.shop.rte
bagel.shop.rte

Expédiez également un fichier " bread.shop.rte.rm_inv vide pour indiquer que tous les fichiers du jeu de fichiers " bagel.shop.rte doivent être supprimés du système.

Ce fichier est utilisé lorsque le jeu de fichiers actuel est conditionné différemment d'un niveau précédent du jeu de fichiers et que le processus d'installation ne doit pas supprimer les fichiers précédemment installés sur la base des entrées du jeu de fichiers dans la base de données d'inventaire.

Un simple changement de nom pour un jeu de fichiers n'est pas suffisant pour nécessiter un fichier " Fileset.rm_inv. Le fichier " Fileset.rm_inv est nécessaire lorsqu'un nouveau jeu de données est soit un sous-ensemble d'un jeu de données précédent, soit un mélange de parties de jeux de données précédents. Si un fichier " Fileset.namelist existe et contient des entrées pour plus d'un jeu de fichiers, vous devez utiliser le fichier " Fileset.rm_inv pour supprimer du système les niveaux de fichiers précédemment installés.

Le fichier " Fileset.rm_inv consiste en un texte ASCII au format stanza. Le nom d'une section est le nom de chemin complet du fichier ou du répertoire à supprimer s'il est trouvé sur le système. Le nom de la strophe se termine par deux points (:) et est suivi d'un caractère de retour à la ligne. Si des attributs suivent le nom de la strophe, ils ont le format suivant Attribut=Valeur. Les attributs sont utilisés pour identifier les liens fixes et les liens symboliques qui doivent être supprimés. Chaque attribut est décrit sur une ligne distincte. La liste suivante décrit les attributs valides qui sont associés au fichier répertorié :

Par exemple, supposons que le jeu de fichiers " U.S.S.R " 19.91.0.0 contienne les fichiers suivants dans le répertoire " /usr/lib: " moscow, " leningrad, " kiev, " odessa et " petrograd " (un lien symbolique vers " leningrad). Les développeurs du produit décident de diviser le jeu de fichiers " U.S.S.R " 19.91.0.0 " en deux jeux de fichiers : " Ukraine.lib 19.94.0.0 et " Russia.lib 19.94.0.0. Le jeu de fichiers " Ukraine.lib contient les fichiers " kiev et " odessa. Le jeu de fichiers " Russia.lib contient le fichier " moscow. Le fichier " leningrad n'existe plus et est remplacé par le fichier " st.petersburg dans le jeu de fichiers " Russia.lib.

Le fichier " Ukraine.lib.rm_inv doit exister car le jeu de fichiers " Ukraine.lib ne remplace pas directement le jeu de fichiers " U.S.S.R. Le fichier " Ukraine.lib.rm_inv doit être vide car aucun fichier ne doit être supprimé lorsque le jeu de fichiers " Ukraine.lib est installé pour nettoyer le jeu de fichiers " U.S.S.R en cours de migration.

/usr/lib/leningrad:
 symlinks = /usr/lib/petrograd
/usr/lib/petrograd:

Fichiers d'installation pour les sous-systèmes de disques supplémentaires

Un sous-système de disques qui ne sera pas configuré avec le pilote de périphérique SCSI ou connecté au bus fourni requiert son propre pilote de périphérique et ses propres méthodes de configuration. Ces fichiers d'installation sont fournis sur une disquette supplémentaire (qui accompagne l'appareil) et doivent être au format de sauvegarde avec un fichier " ./signature et un fichier " ./startup. Le fichier de signature doit contenir la chaîne " target. Le fichier de démarrage doit utiliser la restauration par nom pour extraire les fichiers nécessaires de la disquette supplémentaire et exécuter les commandes nécessaires pour faire passer l'unité à l'état disponible.

Format des supports de distribution

Les types de support suivants peuvent être utilisés pour distribuer des packages d'installation de produits logiciels.

Les sections suivantes décrivent les formats qui doivent être utilisés pour distribuer plusieurs packages de produits sur chacun de ces supports.

Bande

Pour empiler plusieurs images de package produit sur une seule bande ou sur un ensemble de bandes, les fichiers de chaque bande de l'ensemble doivent être au format suivant:

• Le fichier 1 est vide. (Réservé aux bandes amorçables.)
• Le fichier 2 est vide. (Réservé aux bandes amorçables.)
• Le fichier 3 contient un fichier de table des matières qui décrit les images de package produit sur l'ensemble de bandes. Par conséquent, chaque bande du jeu contient une copie du même fichier de table des matières, à l'exception de la différence du numéro de volume de bande dans un jeu multivolume.
• Les fichiers 4 à(N+3) contiennent les images des fichiers au format de sauvegarde pour les paquets de produits " 1 à N.
• Un fichier image de package produit ne peut pas s'étendre sur deux bandes.
• Chaque fichier est suivi d'une marque de fin de fichier.

disque compact à mémoire en lecture seule

Un CD-ROM qui doit contenir plusieurs images de package de produit doit être conforme au protocole Rock Ridge Group. Les paquets de produits doivent être stockés dans le répertoire d'installation, qui doit contenir les éléments suivants :

• Images de fichier de format de sauvegarde des packages du produit.
• Un fichier de table des matières nommé " .toc qui décrit les images de l'emballage du produit dans le répertoire.

Un CD-ROM à plusieurs volumes est un CD-ROM qui possède une structure de répertoire supplémentaire pour définir un ensemble de CD-ROM en tant qu'unité installable unique.

Un CD-ROM en plusieurs volumes doit respecter les règles suivantes :

• Il existe un répertoire " /installp/mvCD dont le contenu est le suivant :
  1. Un fichier de table des matières (.toc) qui décrit les images de l'emballage du produit sur tous les CD-ROM de l'ensemble. Chaque volume du CD-ROM doit avoir le même " .toc dans le " /installp/mvCD.
  2. Un fichier ASCII nommé volume_id dans lequel la première ligne est constituée du numéro de volume décimal du CD dans l' set1.
  3. Un lien symbolique nommé " vol% n, où n est le numéro de volume décimal du CD dans l'ensemble. La cible du lien symbolique doit être un chemin d'accès relatif au répertoire des packages du produit sur ce volume particulier du CD. La valeur standard du lien symbolique est " ../ppc.
• Le fichier de table des matières (.toc) dans le " /installp/mvCD est conforme au format standard de table des matières. La caractéristique particulière du volume multiple " .toc est que l'emplacement de chaque image d'emballage de produit commence par l'entrée de répertoire " vol% n, où n indique le volume qui contient cet emballage de produit particulier.

Exemple AIX 5.2

le jeu de fichiers A se trouve dans le fichier " A.bff du volume 1. Le jeu de fichiers B se trouve dans le fichier " B.bff du volume 2. Les champs du fichier de la table des matières dans " /installp/mvCD contenant l'emplacement des images de l'emballage du produit pour A et B sont respectivement " vol%1/A.bff et " vol%2/B.bff Le champ du fichier de la table des matières dans le " /installp/ppc du volume 1 contient l'emplacement de A en tant que " A.bff. Le champ du fichier de la table des matières dans le " /installp/ppc du volume 2 contient l'emplacement de B en tant que " B.bff.

La structure de répertoire du CD-ROM pour AIX 5.1 et versions ultérieures permet de spécifier d'autres programmes d'installation, ainsi que plusieurs plateformes.

Disquette

Pour empiler plusieurs images de package de produit sur un ensemble de disquettes, les fichiers suivants doivent être écrits sur l'ensemble de disquettes:

• Fichier de table des matières qui décrit les images de package de produit à inclure dans l'ensemble.
• Chaque fichier image de package de produit à inclure dans l'ensemble.

Les fichiers sont écrits sur le jeu de disquettes selon les règles suivantes :

• Ecrivez les données sous forme de flux dans le jeu de disquettes avec un secteur d'ID volume inséré dans le bloc 0 de chaque disquette du jeu. Les données du dernier bloc d'un volume sont traitées comme étant logiquement à la suite des données du bloc 1 du volume suivant (le secteur d'identification du volume est vérifié et écarté lors de la lecture).
• Chaque fichier commence sur une limite de bloc de 512 octets.
• Ecrivez d'abord le fichier de la table des matières. Remplir le dernier secteur de ce fichier avec des caractères nuls (x'00'). Au moins un caractère nul est nécessaire pour marquer la fin du fichier de la table des matières. Par conséquent, un secteur complet de caractères nuls peut être requis.
• Après le fichier de la table des matières, écrivez chacun des fichiers image du package produit dans des secteurs successifs. Remplir le dernier secteur de chaque fichier en utilisant des caractères nuls. Un caractère null n'est pas requis si le fichier se termine à la limite du bloc.
• Le bloc 0 de chaque disquette du jeu contient un secteur d'ID volume. Le format de ce secteur est le suivant:

  Organisation/Position	Descriptif
  Octets 0: 3	Un nombre magique pour l'identification. Il s'agit d'un nombre entier binaire dont la valeur est le " 3609823513=x'D7298918'" décimal.
  Octets 4:15	Une date et un horodatage (en ASCII) qui servent à identifier le jeu de disquettes. Le format est le suivant : MonthDayHourMinuteSecondYear. L'heure doit être une valeur comprise entre 00 et 23. Toutes les zones de date et d'heure contiennent deux chiffres. Ainsi, le mois doit être représenté par le " 03 au lieu du " 3 et l'année par le " 94 au lieu du " 1994.
  Octets 16:19	Numéro de volume entier binaire dans cet ensemble de disquettes. La première disquette du jeu est " x'00000001'.
  Octets 20:511	Zéros binaires.

Tableau 7. Le fichier de table des matières

Nom de zone	Format	Séparateur	Descriptif
1. Volume	Caractère	Blanc	Pour le fichier de table des matières de la bande et de la disquette, il s'agit du numéro du volume contenant ces données. Pour le fichier de table des matières du disque dur ou du CD-ROM, le numéro de volume est " 0.
2. Date et horodatage	mmddhhMMssyy	Blanc	Pour une bande ou une disquette, il s'agit de l'horodatage de la création du volume 1. Pour les disques durs ou les CD-ROM, il s'agit de l'heure à laquelle le fichier " .toc " a été créé. Voir Format de date et d'horodatage plus loin dans cet article pour une description détaillée.
3. Format d'en-tête	Caractère	Nouvelle ligne	Nombre indiquant le format du fichier de table des matières. Les entrées valides sont : 1-AIX version 3.1 2 -Version 3.2 3-AIX Version 4.1 ou ultérieure B - bande mksysb (non valable pour l'utilisation par le " installp)
4. Emplacement de l'image du package du produit	Caractère	Blanc	Pour une bande ou une disquette, il s'agit d'une chaîne de caractères de la forme : vvv:bbbbb:sssssss Voir Format d'emplacement pour bande et disquette plus loin dans cet article pour une description détaillée. Pour un disque dur ou un CD-ROM, il s'agit du nom du fichier de l'image du paquet de produits. Il s'agit uniquement du nom du fichier, qui ne doit être précédé d'aucune partie du nom du chemin d'accès.
5. Informations spécifiques au paquet	lpp_name format de fichier	Nouvelle ligne	Le contenu du fichier " lpp_name contenu dans l'image de l'emballage du produit. Voir le fichier d'informations sur le package lpp_name pour une description détaillée.

Note : Les points 4 et 5 décrits dans le tableau précédent sont répétés pour chaque image d'emballage de produit contenue sur le support.

Format de la date et de l'horodatage

Un format de date et d'horodatage est une chaîne ASCII qui a le format suivant :

MonthDayHourMinuteSecondYear

L'heure doit être une valeur comprise entre 00 et 23. Toutes les zones de date et d'heure contiennent deux chiffres. Ainsi, le mois doit être représenté par le " 03 au lieu du " 3 et l'année par le " 94 au lieu du " 1994.

Format de localisation pour les bandes et les disquettes

L'emplacement est au format vvv:bbbbb:sssssss où chaque lettre représente un chiffre et a la signification suivante:

Pour une bande

vvv

Est le numéro de volume de la bande.

bbbbb

Il s'agit du numéro de fichier figurant sur la bande de l'image de l'emballage du produit.

SSSSSSSS

Taille du fichier en octets.

Pour disquette

vvv

Est le numéro de volume de la disquette.

bbbbb

Numéro de bloc sur la disquette où commence le fichier image de l'emballage du produit.

SSSSSSSS

Taille du fichier en octets (y compris le remplissage jusqu'à la fin du bloc).

AIX Installation délocalisable

Bien que l'installation relocalisable d'AIX soit désormais prise en charge par les utilitaires d'installation natifs d'AIX (tels que " installp, " instfix, " lslpp et " lppchk), l'utilisation de la relocalisation présente un intérêt particulier pour les applications qui doivent être installées au sein d'une partition de charge de travail. En effet, les configurations par défaut du système WPAR ne comprennent pas de système de fichiers " /usr ou " /opt accessible en écriture. Par conséquent, il peut être nécessaire de recibler l'installation de l'application sur des emplacements autres que le traditionnel " /usr ou " /opt

Terminologie

USIL

Un emplacement d'installation spécifié par l'utilisateur, ou USIL, est un chemin d'installation relocalisé suivi qui est créé par l'administrateur. Cet emplacement est suivi par le système et peut être utilisé comme chemin d'installation alternatif pour les paquets qui prennent en charge la relocalisation. Plusieurs instances et/ou versions d'un même progiciel peuvent être installées sur un seul système en déléguant chaque installation à une USIL distincte. Une instance USIL existante peut être connectée ou déconnectée d'un système donné.

Commandes de gestion de l'USIL

Utilitaires d'installation retraitables

Exigences relatives à l'emballage des applications délocalisables

Exigences relatives à l'exécution d'une application délocalisable

Objet de classe ODM du connecteur USIL

L'objet de classe ODM connecteur USIL réside dans le fichier " /etc/objrepos/usilc et contient des données qui relient le SWVPD par défaut à toutes les instances USIL.

/*  User Install Location Connector                                    */
/*  Connects the default install path to all relocated install paths.  */
class   usilc {
        vchar   path[1024];             /* USIL path */
        vchar   comments[2048];   /* USIL Comments */
        long    flags;                       /* USIL flags */
        };     

Liste de tous les chemins d'installation avec l'option '-R "ALL" ou '-R "all"

Les commandes " lslpp et " lppchk peuvent effectuer des opérations de listage sur tous les emplacements d'installation si la syntaxe " -R "ALL" est utilisée.

Opérations d'attachement/détachement

L'opération " attach permet à l'utilisateur d'intégrer un chemin USIL détaché existant dans le SWVPD.

Par exemple, si l'administrateur crée une instance USIL primaire avec diverses applications délocalisables installées à des fins d'hébergement d'applications. L'administrateur copie ou monte NFS cette instance USIL sur différents systèmes et utilise la fonction " attach pour intégrer l'instance USIL dans le SWVPD. L'opération de détachement supprime la référence à l'instance USIL.

installp licences

Une nouvelle instance USIL démarre avec un LAG vide (classe d'objets ODM accord de licenceinstallp ). Toute installation de jeux de fichiers ou de LPP nécessitant une licence devra faire l'objet d'une acceptation de licence conformément aux conventions normales du " installp L'acceptation de la licence ne couvre pas les instances USIL.

Trusted Computing Base (TCB)

L'installation d'instances USIL n'est actuellement pas prise en charge sur les systèmes activés par TCB.

Conditions requises pour la relocalisation

Une nouvelle sémantique de conditionnement indique l'emplacement requis relocalisable. L'empaqueteur peut spécifier qu'un requisite donné doit se trouver dans le chemin d'installation par défaut ou dans le chemin d'installation relocalisé.

Les types de réquisitions actuellement définis (prereq, " ifreq, " coreq et " instreq) sont tous des réquisitions par défaut (réquisitions qui s'appliquent à l'emplacement d'installation par défaut).

Modifications de la table des matières des packages relocalisables

sscp.rte.1.0.0.5.U.PRIVATE.bff 4 R S sscp {
sscp.rte 01.00.0000.0005 1 N B En_US Sscp
[
*coreq bos.games 1.1.1.1  <-- default requisite in default requisite section
*prereq bos.rte 1.1.1.1   <-- default requisite in default requisite section
%
/usr/bin 20
/etc 20
INSTWORK 72 40
%
%
%
IY99999  1 APAR text here.
%
RELOCATABLE <-- attribute tag to denote relocatable package
%
*prereq bos.rte 1.1.1.1 <-- default requisite in relocated requisite section
*coreq_r bos.games 1.1.1.1 <-- relocated requisite in relocated requisite section
]
}

Les exécutables fournis dans le cadre d'un ensemble de produits peuvent adapter le traitement des opérations d'application, de rejet et de suppression.

La réinstallation d'un ensemble de fichiers n'effectue pas les mêmes actions que la suppression et l'installation du même ensemble de fichiers. L'action de réinstallation (voir " /usr/lib/instl/rminstal) nettoie les fichiers actuels de la version précédente ou de la même version, mais n'exécute aucun des scripts " unconfig ou " unpre*. Par conséquent, ne supposez pas que le script " unconfig a été exécuté. Le script '.config doit vérifier l'environnement avant de supposer que la reconfiguration a été effectuée.

Par exemple, pour un jeu de fichiers " ras.berry.rte, le script de configuration ajoute une ligne au fichier " crontab de la racine. La réinstallation du jeu de fichiers " ras.berry.rte entraîne deux entrées " crontab car le script " unconfig n'a pas été exécuté lors de la réinstallation (ce qui a supprimé l'entrée " crontab ). Le script de configuration doit toujours supprimer l'entrée, puis l'ajouter à nouveau.

Traitement de l'opération " apply

Cette section décrit les étapes suivies par la commande " installp lors de l'application d'un jeu de fichiers ou d'une mise à jour d'un jeu de fichiers.

1. Restaurer le fichier d'informations sur l'emballage du produit " lpp_name pour l'emballage à partir du périphérique spécifié.
2. Vérifiez que les ensembles de fichiers demandés existent sur le support d'installation.
3. Vérifiez le niveau des ensembles de fichiers demandés pour vous assurer qu'ils peuvent être installés sur le système.
4. Restaurer les fichiers de contrôle du fichier d'archive 'liblpp.a dans le répertoire du paquet (/usr/lpp/Package_Name pour les paquets 'usr ou 'usr/root ). Les fichiers de contrôle spécifiques à la partie " root d'un paquet " usr/root résident dans " /usr/lpp/Package_Name/inst_root/liblpp.a).
5. Vérifiez l'espace disque requis.
6. Vérifiez que les requisites nécessaires (jeux de fichiers qui doivent être à certains niveaux pour utiliser ou installer un autre jeu de fichiers) sont déjà installés ou figurent sur la liste des jeux de fichiers à installer.
7. Déterminez s'il existe des exigences en matière d'accord de licence qui doivent être satisfaites pour procéder à l'installation.
8. S'il s'agit d'un paquet d'installation plutôt que d'un paquet de mise à jour de jeux de fichiers, effectuez une recherche dans les données vitales du produit logiciel (SWVPD) pour voir si Fileset (le jeu de fichiers en cours d'installation) ou tout autre jeu de fichiers répertorié dans le fichier 'Fileset.namelist est déjà installé sur le système, à quelque niveau que ce soit. Si le Fileset est déjà installé, écrivez le nom du Fileset et le niveau d'installation dans le fichier 'Work_Directory/Fileset.installed_list.

   Si aucun niveau d'ensemble de fichiers n'est installé, si l'un des ensembles de fichiers énumérés dans le fichier " Fileset.namelist est installé, il faut énumérer tous ces ensembles de fichiers et niveaux dans le fichier " Work_Directory/Fileset.installed_list ". Work_Directory est identique au répertoire du paquet, à l'exception des parties de la racine, qui utilisent " /lpp/Package_Name.

9. S'il s'agit d'un paquet d'installation plutôt que d'un paquet de mise à jour de jeux de fichiers, exécutez le script '/usr/lib/instl/rminstal pour effectuer les opérations suivantes pour chaque jeu de fichiers en cours d'installation.
   Note : Sauf indication contraire, les fichiers dont l'existence est vérifiée doivent avoir été restaurés à partir de la bibliothèque de fichiers de contrôle " liblpp.a
   1. Si 'Fileset.pre_rm existe, exécutez 'Fileset.pre_rm pour effectuer les étapes requises avant de supprimer des fichiers de cette version ou d'une version existante du Fileset.
   2. Si " Work_Directory/Fileset.installed_list existe, déplacez les fichiers existants énumérés dans " Fileset.cfgfiles vers le répertoire de sauvegarde du fichier de configuration (indiqué par la variable d'environnement " MIGSAVE ).
   3. Si une version de Fileset est déjà installée, supprimez les fichiers et les informations SWVPD (sauf l'historique) pour Fileset.
   4. Si " Work_Directory/Fileset.installed_list existe et si " Fileset.rm_inv existe ou si " Fileset.namelist contient plus d'un jeu de fichiers ou si le seul jeu de fichiers répertorié dans " Fileset.namelist est " bos.obj, procédez comme suit :
      1. Supprimer les fichiers et les informations d'inventaire SWVPD pour les fichiers répertoriés dans le fichier " Fileset.rm_inv.
      2. Supprimer les fichiers et les informations d'inventaire SWVPD pour les fichiers répertoriés dans le fichier " Fileset.inventory.
      3. Supprimer les autres informations SWVPD pour tous les jeux de fichiers énumérés dans le " Fileset.namelist qui n'ont plus d'informations d'inventaire SWVPD.
   5. Si " Work_Directory/Fileset.installed_list existe et ne contient qu'un seul jeu de fichiers et si " Fileset.namelist ne contient qu'un seul jeu de fichiers, supprimer les fichiers et les informations SWVPD (à l'exception de l'historique) pour ce jeu de fichiers.
   6. Pour chaque partie d'un ensemble de produits (partie usr uniquement ou " usr suivi de la racine)
      1. Définissez les variables d'environnement INUTREE(U pour 'usr et M pour root) et INUTEMPDIR (nom du répertoire de travail temporaire créé).
      2. Si un programme de contrôle " instal existe dans le répertoire du paquet (ce qui n'est pas recommandé), exécutez " ./instal, sinon, exécutez le script par défaut " /usr/lib/instl/instal. Si le programme de contrôle " instal n'existe pas dans le répertoire du paquet, définissez la variable d'environnement " INUSAVEDIR
      3. Si un programme de contrôle " update existe dans le répertoire du paquet (ce qui n'est pas recommandé), exécutez " ./update. Si le programme de contrôle " update n'existe pas dans le répertoire du paquet, exécutez le script par défaut " /usr/lib/instl/update.
      4. Si un fichier " status a été créé avec succès par " instal ou " update, utilisez le fichier " status pour déterminer le succès ou l'échec de chaque jeu de fichiers. Si un fichier " status n'a pas été créé, il faut supposer que tous les jeux de fichiers demandés dans le paquet n'ont pas été appliqués.
      5. Si l'opération " apply pour un jeu de fichiers a réussi, mettez à jour les données vitales du produit logiciel (SWVPD), puis enregistrez toutes les exigences liées à l'accord de licence. Si l'opération 'apply pour un jeu de fichiers n'a pas réussi, exécutez '/usr/lib/instl/cleanup ou le 'lpp.cleanup ' fourni par le paquet à partir du répertoire du paquet pour nettoyer les jeux de fichiers qui ont échoué.

Traitement du script d'installation ou de mise à jour par défaut

L'exécutable " instal ou " update est appelé à partir de " installp, le premier paramètre étant l'appareil utilisé pour l'installation ou la mise à jour. Le deuxième paramètre est le chemin d'accès complet au fichier contenant la liste des jeux de fichiers à installer ou à mettre à jour, appelé " $FILESETLIST. Les scripts par défaut " instal et " update sont liés ; le traitement varie selon qu'il est invoqué en tant que " instal ou " update. Le répertoire courant est le répertoire du paquet. Un répertoire temporaire INUTEMPDIR est créé dans '/tmp pour contenir les fichiers de travail.

Le flux des scripts par défaut " instal et " update est le suivant :

1. Effectuez les opérations suivantes pour chaque jeu de fichiers répertorié dans le " $FILESETLIST:
   1. Si le jeu de fichiers est une mise à jour, exécuter le " Fileset.pre_u (pre_update) s'il existe. Si le jeu de fichiers n'est pas une mise à jour, exécuter le " Fileset.pre_i (pré_installation) s'il existe.
   2. Créez une liste primaire des fichiers à restaurer à partir du paquet en ajoutant " Fileset.al au nouveau fichier " INUTEMPDIR/master.al.
   3. S'il s'agit d'une mise à jour, les fichiers sont spécifiés pour être sauvegardés et le fichier de contrôle de l'archive " lpp.acf existe.

      Sauvegardez les membres de l'archive de bibliothèque en cours de mise à jour.

   4. Si le traitement est réussi, ajoutez ce jeu de fichiers à la liste des fichiers à installer dans le fichier " $FILESETLIST.new ".
2. S'il s'agit d'une mise à jour et que l'enregistrement des fichiers est spécifié, exécutez " inusave pour enregistrer les versions actuelles des fichiers.
3. Si vous traitez la partie " root, exécutez " inucp pour copier les fichiers de la liste d'application vers la partie " root. Si vous ne traitez pas la partie " root, exécutez " inurest pour restaurer les fichiers de la liste d'application pour la partie " usr.
4. Effectuez les opérations suivantes pour chaque jeu de fichiers répertorié dans le fichier " $FILESETLIST.new:
   Remarque : l'échec d'une étape est enregistré dans le fichier " status et le traitement de ce jeu de fichiers s'arrête
   1. Déterminez si ce jeu de fichiers est installé au même niveau ou à un niveau plus ancien, ou si les jeux de fichiers répertoriés dans le " Fileset.namelist sont installés. Si c'est le cas, exportez les variables d'environnement 'INSTALLED_LIST et 'MIGSAVE C'est ce qu'on appelle une migration.
   2. Si vous traitez une mise à jour, invoquez le " Fileset.post_u s'il existe. Si le " Fileset.post_u n'existe pas, invoquer le " Fileset.post_i s'il existe.
   3. Si " Fileset.cfgfiles existe, exécutez " /usr/lib/instl/migrate_cfg pour traiter les fichiers de configuration selon la méthode spécifiée.
   4. Invoquer " sysck pour ajouter les informations du fichier " Fileset.inventory à la base de données des produits logiciels (SWVPD).
   5. Invoquer la commande " tcbck pour ajouter les informations relatives à la base de calcul de confiance au système si le fichier " Fileset.tcb existe et si l'attribut " tcb_enabled de la base de calcul de confiance est défini dans la base de données ODM " /usr/lib/objrepos/PdAt
   6. Invoquer " errupdate pour ajouter des modèles d'erreur si " Fileset.err existe.
   7. Invoquer " trcupdate pour ajouter des modèles de format de rapport de traçage si " Fileset.trc existe.
   8. En cas de mise à jour ou si " Work_Directory/Fileset.installed_list existe, invoquer chaque script " Fileset.odmdel et " Fileset.*.odmdel pour traiter les commandes de suppression de la base de données du ODM.
   9. Invoquer " odmadd sur chaque " Fileset.odmadd et " Fileset.*.odmadd existant pour ajouter des informations aux bases de données de ODM.
   10. S'il s'agit d'une mise à jour, invoquez le " Fileset.config_u (mise à jour de la configuration du jeu de fichiers) s'il existe. Sinon, il invoque le " Fileset.config (configuration du jeu de fichiers) s'il existe.
   11. Mise à jour du fichier " status indiquant que le traitement du jeu de données a été effectué avec succès.
5. Lier les fichiers de contrôle nécessaires au retrait des jeux de fichiers dans le répertoire " deinstl du paquet pour une utilisation ultérieure. Ces fichiers incluent les fichiers suivants qui peuvent être présents dans le répertoire du package:
   • lpp.deinstal
   • Fileset.al
   • Fileset.inventory
   • Fileset.pre_d
   • Fileset.unpre_i
   • Fileset.unpre_u
   • Fileset.unpost_i
   • Fileset.unpost_u
   • Fileset.unodmadd
   • Fileset.unconfig
   • Fileset.unconfig_u
   • $SAVEDIR/Fileset.*.rodmadd
   • SAVEDIR/Fileset.*.unodmadd

Traitement des opérations de rejet et de nettoyage

Cette section décrit les étapes suivies par la commande 'installp lorsqu'une mise à jour d'un jeu de fichiers est rejetée ou lorsqu'un jeu de fichiers ou une mise à jour d'un jeu de fichiers ne parvient pas à terminer l'installation. Les scripts par défaut " cleanup et " reject situés dans " /usr/lib/instl sont liés entre eux. Leur logique diffère légèrement selon que le script a été invoqué en tant que " reject ou " cleanup. Pour les jeux de fichiers usr ou " root ou les mises à jour de jeux de fichiers, la partie " root est traitée avant la partie " usr.

1. En cas de rejet, vérifiez les conditions requises pour vous assurer que toutes les mises à jour de produit dépendantes sont également rejetées.
2. Pour chaque partie d'un paquet (par exemple, 'usr et root) :
   1. Définir les variables d'environnement 'INUTREE (U pour 'usr et M pour root) et 'INUTEMPDIR.
   2. Si le fichier de contrôle " reject existe dans le répertoire actuel (INULIBDIR), invoquer " ./lpp.reject. Dans le cas contraire, le script par défaut " /usr/lib/instl/reject est invoqué.
3. Mettez à jour les données techniques essentielles du logiciel.

L'exécutable " reject est appelé à partir de " installp, le premier paramètre étant indéfini et le second étant le chemin d'accès complet au fichier contenant la liste des jeux de fichiers (appelé " $FILESETLIST) à rejeter pour la mise à jour.

Les fichiers suivants sont référencés par les scripts par défaut " cleanup et " reject

Le flux des scripts par défaut " cleanup et " reject est le suivant :

1. Effectuez les opérations suivantes pour chaque jeu de fichiers répertorié dans " $FILESETLIST:
   1. S'il est invoqué en tant que " cleanup, il lit la ligne du fichier d'état " Package_Name.s pour déterminer l'étape à laquelle l'installation a échoué et passe à l'action d'annulation pour cette étape. Une opération " cleanup ne commence qu'à l'étape où l'installation a échoué. Par exemple, si l'installation d'un jeu de fichiers a échoué dans le script " Fileset.post_i, l'opération de nettoyage de ce jeu de fichiers commencera à i, car il n'y a pas d'actions à annuler dans les étapes suivantes de l'installation.
   2. Annulez tout traitement de configuration effectué lors de l'installation:

      En cas de rejet d'une mise à jour, invoquer le " Fileset.unconfig_u s'il existe. Sinon, il invoque le " Fileset.unconfig s'il existe.

   3. Exécutez les fichiers 'Fileset.*.unodmadd et/ou 'Fileset.unodmadd pour supprimer les entréesODMObject Data Manager) ajoutées lors de l'installation.
   4. Exécutez tout " Fileset.*.rodmadd et/ou " Fileset.rodmadd existant pour remplacer les entrées ODM supprimées lors de l'installation.
   5. Invoquer 'trcupdate si 'Fileset.undo.trc existe pour annuler toute modification du modèle de format de trace effectuée au cours de l'installation.
   6. Invoquer " errupdate si " Fileset.undo.err existe pour annuler toute modification du modèle de format d'erreur effectuée au cours de l'installation.
   7. Invoquer " tcbck pour supprimer les informations relatives à la base de calcul de confiance du système si le fichier " Fileset.tcb existe et si l'attribut " tcb_enabled de la base de calcul de confiance est défini dans la base de données ODM " /usr/lib/objrepos/PdAt
   8. Invoquer le " sysck si le " Fileset.inventory existe pour annuler les modifications apportées à la base de données d'informations sur les logiciels.
   9. Annuler tout traitement post-installation effectué pendant l'installation :

      S'il s'agit d'une mise à jour, invoquer le " Fileset.unpost_u s'il existe. Sinon, il invoque le " Fileset.unpost_i s'il existe.

   10. Construire une liste d'application primaire (appelée " master.al) à partir des fichiers " Fileset.al
   11. Ajouter le jeu de fichiers à '$FILESETLIST.new.
2. Procédez comme suit si le " $INUTEMPDIR/master.al existe.
   1. Changez de répertoire pour 'root (/).
   2. Supprimer tous les fichiers dans 'master.al.
3. Effectuez les opérations suivantes lors de la lecture du " $FILESETLIST.new.
   1. Appelez le " inurecv pour récupérer tous les fichiers sauvegardés.
   2. S'il s'agit d'une mise à jour, invoquer le " Fileset.unpre_u s'il existe. Sinon, il invoque le " Fileset.unpre_i s'il existe.
   3. Supprimez les fichiers de contrôle d'installation/de mise à jour.
4. Supprimer le fichier d'état 'Package_Name.s

Traitement de l'opération " remove

Cette section décrit les étapes suivies par la commande " installp lorsqu'un jeu de fichiers est supprimé. Pour l'utilisation ou les jeux de fichiers " root ou les mises à jour de jeux de fichiers, la partie " root est traitée avant la partie "usr".

1. Vérifiez les prérequis pour vous assurer que tous les ensembles de fichiers dépendants sont également supprimés.
2. Pour chaque partie d'un ensemble de produits (par exemple, " usr ou racine) :
   1. Définir les variables d'environnement 'INUTREE (U pour usr, M pour root, et S pour share) et INUTEMPDIR (installp répertoire de travail généré dans '/tmp).
   2. Modifier le répertoire en " INULIBDIR.
   3. Si le fichier de contrôle 'deinstal existe dans le répertoire courant, exécuter le script './lpp.deinstal Si le fichier de contrôle " deinstal n'existe pas dans le répertoire actuel, le script par défaut " /usr/lib/instl/deinstal est exécuté.
3. Supprimez du système de fichiers les fichiers appartenant à l'ensemble de fichiers.
4. Supprimez les entrées d'ensemble de fichiers de SWVPD, à l'exception des données d'historique.
5. Désactiver l'enregistrement des exigences du contrat de licence pour le jeu de fichiers.

L'exécutable " deinstal est appelé à partir de " installp, le premier paramètre étant le chemin d'accès complet au fichier contenant la liste des jeux de fichiers à supprimer, appelé " $FILESETLIST.

Le flux du script par défaut " deinstal est le suivant :

1. Effectuez les opérations suivantes pour chaque jeu de fichiers figurant dans le fichier d'entrée " $FILESETLIST:
2. Si " Fileset.unconfig_d existe

   Exécutez le " Fileset.unconfig_d pour supprimer toutes les modifications de configuration, les modifications de l'ODMObject Data Manager) et les modifications des formats d'erreur et de trace, et pour annuler toutes les opérations effectuées dans les scripts de post-installation et de pré-installation pour toutes les mises à jour et l'installation de base. L'utilisation de ce fichier n'est pas recommandée.

3. Si " Fileset.unconfig_d n'existe pas,
   1. Pour chaque mise à jour de cet ensemble de fichiers, procédez comme suit:
      • Exécuter tous les scripts " Fileset.unconfig_u pour annuler tout traitement de la configuration de la mise à jour.
      • Exécutez tous les " Fileset.*.unodmadd et " Fileset.unodmadd pour supprimer les entrées de lODMObject Data Manager) ajoutées lors de la mise à jour.
      • Exécutez tous les " Fileset.*.rodmadd et " Fileset.rodmadd pour ajouter les entrées du gestionnaire de données d'objetsODM supprimées lors de la mise à jour.
      • Exécuter 'errupdate si 'Fileset.undo.err existe pour annuler les modifications apportées au modèle de journal des erreurs.
      • Exécuter " trcupdate si " Fileset.undo.trc existe pour annuler les modifications apportées au modèle de rapport de traçage.
      • Exécutez n'importe quel " Fileset.unpost_u pour annuler toute personnalisation postérieure à l'installation.
   2. Pour le niveau d'installation de base de l'ensemble de fichiers, procédez comme suit:
      • Exécutez n'importe quel " Fileset.*.unodmadd et/ou " Fileset.unodmadd pour supprimer les entrées de lODMObject Data Manager) ajoutées lors de l'installation.
      • Exécutez n'importe quel " Fileset.*.rodmadd et/ou " Fileset.rodmadd pour ajouter les entrées du gestionnaire de données d'objetsODM supprimées lors de l'installation.
      • Exécuter 'errupdate si 'Fileset.undo.err existe pour annuler les modifications apportées au modèle de journal des erreurs.
      • Exécuter " trcupdate si " Fileset.undo.trc existe pour annuler les modifications apportées au modèle de rapport de traçage.
      • Exécutez " Fileset.unconfig_i pour annuler tout traitement de la configuration de l'installation.
      • Exécutez 'Fileset.unpost_i pour annuler toute personnalisation postérieure à l'installation du fichier.
4. Supprimer les fichiers et les informations de données logicielles installés avec le jeu de fichiers.
5. Si " Fileset.unconfig_d n'existe pas,
   1. Pour chaque mise à jour de ce jeu de fichiers, exécutez n'importe quel " Fileset.unpre_u pour annuler toute personnalisation antérieure à l'installation du fichier.
   2. Pour le niveau d'installation de base du jeu de fichiers, exécutez n'importe quel " Fileset.unpre_i pour annuler toute personnalisation antérieure à l'installation du jeu de fichiers.
6. Supprimez tous les répertoires vides associés à l'ensemble de fichiers.
   Remarque : si un appel renvoie une erreur pendant l'exécution de l'exécutable " deinstal, l'erreur est enregistrée, mais l'exécution se poursuit. Cela est différent des autres scripts car l'exécution de cet ensemble de fichiers est normalement annulée lorsqu'une erreur est détectée. Cependant, une fois que la suppression d'un ensemble de fichiers a commencé, il n'y a pas de récupération ; par conséquent, la suppression devient un meilleur effort une fois qu'une erreur est détectée.

Le fichier d'état de l'installation

La commande " installp utilise ce fichier " status pour déterminer le traitement approprié. Si vous créez des scripts d'installation, ceux-ci doivent produire un fichier " status au format correct. Chaque ligne du fichier " status a le format suivant :

L'exemple suivant d'un fichier " status indique à la commande " installp que les installations des jeux de fichiers " tcp.client et " tcp.server du paquet " bos.net ont réussi et que l'installation du jeu de fichiers " nfs.client a échoué.

s bos.net.tcp.client
s bos.net.tcp.server
f bos.net.nfs.client

Commandes d'installation utilisées lors de l'installation et de la mise à jour

Pour des exemples d'utilisation, voir le script d'installation par défaut, " /usr/lib/instl/instal.