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

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.


Remarque –

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.


Attention – Attention –

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.


Remarque –

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