Format du fichier prototype

Format de chaque ligne du fichier prototype :

partftypeclasspathmajorminormodeownergroup

Seuls les champs ftype, class, path, mode, owner et group sont habituellement définis. Ces champs sont décrits dans les sections suivantes. Reportez-vous à la page de manuel prototype(4) pour plus d'informations sur ces champs.

Champ ftype

Le champ ftype (type de fichier) est un champ à un caractère qui indique le type de fichier de l'objet du package. Les types de fichier valides sont décrits dans le tableau suivant :

Champ class

Le champ class nomme la classe à laquelle un objet appartient. L'utilisation des classes est une fonction de conception de package facultative. Cette fonction est traitée en détail à la la rubrique Rédaction de scripts d'action de classe.

Lorsque vous n'utilisez pas de classes, les objets appartiennent à la classe none. Lorsque vous exécutez la commande pkgmk pour créer votre package, la commande insère le paramètre CLASSES=none dans le fichier pkginfo. Les fichiers dont le type est i doivent contenir un champ class vide.

Champ path

Le champ path sert à définir le répertoire dans lequel l'objet du package réside sur le système cible. Vous pouvez indiquer l'emplacement à l'aide d'un nom de chemin absolu (par exemple, /usr/bin/mail) ou d'un nom de chemin relatif (par exemple, bin/mail). L'utilisation d'un nom de chemin absolu signifie que l'emplacement de l'objet sur le système cible est défini par le package et ne peut être modifié. Un objet de package dont le nom de chemin est relatif est réadressable.

Un objet réadressable n'a pas besoin d'un chemin absolu sur le système cible. Son emplacement est en fait déterminé au cours de la procédure d'installation.

Vous pouvez définir certains, voire l'ensemble des objets d'un package comme étant des objets réadressables. Avant de rédiger des scripts d'installation ou de créer le fichier prototype, décidez si les objets du package doivent avoir un emplacement fixe (tels les scripts de démarrage dans /etc) ou s'ils doivent être réadressables.

Il existe deux types d'objet réadressable, ceux qui sont réadressables collectivement et ceux qui sont réadressables individuellement.

Objets réadressables collectivement

Les objets réadressables collectivement sont situés relativement à une base d'installation commune appelée le répertoire de base. Un répertoire de base est défini dans le fichier pkginfo à l'aide du paramètre BASEDIR. Par exemple, un objet réadressable figurant dans le fichier prototype appelé tests/generic nécessite que le fichier pkginfo définisse le paramètre BASEDIR par défaut. Exemple :

BASEDIR=/opt

Cet exemple signifie que lors de son installation, l'objet est placé dans le répertoire /opt/tests/generic.

Le répertoire /opt est le seul répertoire dans lequel tout logiciel n'appartenant pas aux logiciels Solaris de base peut être installé.

Servez-vous autant que possible d'objets réadressables collectivement. De manière générale, la majeure partie d'un package peut être réadressable à l'aide de quelques fichiers (notamment les fichiers placés dans /etc ou /var) définis comme absolus. Toutefois, si un package contient divers emplacements de réadressage, envisagez la séparation du package en plusieurs packages employant des valeurs BASEDIR distinctes dans leurs fichiers pkginfo.

Objets réadressables individuellement

Les objets réadressables individuellement ne sont pas limités au même répertoire que les objets réadressables collectivement. Pour définir un objet réadressable individuellement, vous devez spécifier une variable d'installation dans le champ path du fichier prototype. Une fois la variable d'installation spécifiée, créez un script request pour demander au programme d'installation le répertoire de base réadressable, ou un script checkinstall pour déterminer le nom du chemin à partir des données du système de fichiers. Pour plus d'informations sur les scripts request, reportez-vous à Rédaction d'un script request, et sur les scripts checkinstall, à Procédure de recueil de données d'un système de fichiers.

Les objets réadressables individuellement sont difficiles à gérer. L'utilisation d'objets réadressables individuellement conduit parfois à la dispersion des composants de package qu'il est alors difficile d'isoler lors de l'installation de plusieurs versions ou architectures du même package. Servez-vous autant que possible d'objets réadressables collectivement.

Noms de chemin paramétriques

Un nom de chemin paramétrique est un nom de chemin qui inclut une spécification de variable. Par exemple, /opt/$PKGINST/nomdefichier est un nom de chemin paramétrique en raison de la spécification de la variable $PKGINST. La valeur par défaut d'une spécification de variable doit être définie dans le fichier pkginfo. La valeur peut ensuite être modifiée par un script request ou un script checkinstall.

La spécification de variable d'un chemin doit se trouver au début ou à la fin du chemin, ou être liée par des barres obliques (/). Un nom de chemin paramétrique valide utilise le format suivant :

$PARAM/tests
tests/$PARAM/generic
/tests/$PARAM

La spécification de variable, une fois définie, peut conduire le chemin à être évalué en tant que chemin absolu ou réadressable. Dans l'exemple ci-après, le fichier prototype contient l'entrée suivante :

f none $DIRLOC/tests/generic

Le fichier pkginfo contient l'entrée suivante :

DIRLOC=/myopt

Le nom de chemin $DIRLOC/tests/generic est évalué comme étant le nom de chemin absolu /myopt/tests/generic, indépendamment de la définition (ou de l'absence de définition) du paramètre BASEDIR dans le fichier pkginfo.

Dans cet exemple, le fichier prototype est identique à celui de l'exemple précédent et le fichier pkginfo contient les entrées suivantes :

DIRLOC=firstcut
BASEDIR=/opt

Le nom de chemin $DIRLOC/tests/generic est évalué comme étant le nom de chemin réadressable /opt/firstcut/tests/generic.

Pour plus d'informations sur les noms de chemin paramétriques, reportez-vous à Utilisation des répertoires de base paramétriques.

Remarques sur les emplacements source et de destination des objets

Le champ path du fichier prototype définit l'emplacement de l'objet sur le système cible. Spécifiez l'emplacement actuel des objets du package dans le fichier prototype si la structure de leurs répertoires ne reproduit pas celle souhaitée sur le système cible. Reportez-vous à Organisation du contenu d'un package pour plus d'informations sur l'organisation des objets d'un package.

Si votre zone de développement n'est pas organisée de la façon souhaitée pour votre package, vous pouvez utiliser le format chemin1=chemin2 dans le champ path. Dans ce format, chemin1 correspond à l'emplacement souhaité pour l'objet sur le système cible et chemin2, à l'emplacement de l'objet sur votre système.

Vous pouvez aussi utiliser le format de nom de chemin chemin1=chemin2, avec chemin1 comme nom d'objet réadressable et chemin2 comme nom de chemin complet d'accès à l'objet en question sur votre système.

chemin1 ne peut pas contenir des variables de création non définies mais peut contenir des variables d'installation non définies. chemin2 ne peut pas contenir des variables non définies bien qu'il soit possible d'utiliser des variables de création ou d'installation. Pour plus d'informations sur les différences entre les variables d'installation et les variables de création, reportez-vous à Variables d'environnement d'un package.

Les liens doivent respecter le format chemin1= chemin2 car ils sont créés à l'aide de la commande pkgadd. En règle générale, la variable chemin2 d'un lien ne doit jamais être absolue ; elle doit par contre être relative à la section du répertoire de chemin1.

Une alternative à l'utilisation du format chemin1=chemin2 est l'utilisation de la commande !search. Pour plus d'informations, reportez-vous à Offre d'un chemin de recherche pour la commande pkgmk..

Champ mode

Le champ mode peut contenir un nombre octal, un point d'interrogation (?) ou une spécification de variable. Le nombre octal indique le mode de l'objet lors de son installation sur le système cible. Le point d'interrogation (?) indique que le mode reste inchangé lors de l'installation de l'objet, impliquant que l'objet du même nom existe déjà sur le système cible.

Une spécification de variable du type $mode, dans laquelle la première lettre de la variable doit être une minuscule, signifie que ce champ est défini lors de la création du package. Notez que cette variable doit être définie lors de la phase de création dans le fichier prototype ou comme option dans la commande pkgmk. Pour plus d'informations sur les différences entre les variables d'installation et les variables de création, reportez-vous à Variables d'environnement d'un package.

Les fichiers de type i (fichier d'information), l (lien physique) et s (lien symbolique) ne doivent rien indiquer dans ce champ.

Champ owner

Le champ owner peut contenir un nom d'utilisateur, un point d'interrogation (?) ou une spécification de variable. Un nom d'utilisateur peut contenir 14 caractères maximum et doit correspondre à un nom existant sur le système cible (tel bin ou root). Le point d'interrogation (?) indique que le propriétaire reste inchangé lors de l'installation de l'objet, impliquant que l'objet du même nom existe déjà sur le système cible.

Une spécification de variable peut être du type $Owner ou $owner, où la première lettre de la variable est une majuscule ou une minuscule. Si la variable commence par une minuscule, elle doit être définie lors de la création du package, dans le fichier prototype ou comme option de la commande pkgmk. Si la variable commence par une majuscule, la spécification de variable est insérée dans le fichier pkginfo comme valeur par défaut et peut être redéfinie lors de l'installation par un script request. Pour plus d'informations sur les différences entre les variables d'installation et les variables de création, reportez-vous à Variables d'environnement d'un package.

Les fichiers dont le type est i (fichier d'information) et lb (lien physique) ne doivent rien indiquer dans ce champ.

Champ group

Le champ group peut contenir un nom d'utilisateur, un point d'interrogation (?) ou une spécification de variable. Un nom de groupe peut contenir 14 caractères maximum et doit correspondre à un nom existant sur le système cible (tel bin ou sys). Le point d'interrogation (?) indique que le groupe reste inchangé lors de l'installation de l'objet, impliquant que l'objet du même nom existe déjà sur le système cible.

Une spécification de variable peut être du type $Group ou $group, où la première lettre de la variable est une majuscule ou une minuscule. Si la variable commence par une minuscule, elle doit être définie lors de la création du package, dans le fichier prototype ou comme option de la commande pkgmk. Si la variable commence par une majuscule, la spécification de variable est insérée dans le fichier pkginfo comme valeur par défaut et peut être redéfinie lors de l'installation par un script request. Pour plus d'informations sur les différences entre les variables d'installation et les variables de création, reportez-vous à Variables d'environnement d'un package.

Les fichiers dont le type est i (fichier d'information) et l (lien physique) ne doivent rien indiquer dans ce champ.