Critères à prendre en considération avant de créer un package

Avant de créer un package, vous devez décider si votre produit doit être composé d'un ou plusieurs packages. Notez que l'installation de plusieurs packages de petite taille est en général plus longue que l'installation d'un seul package de grande taille. Bien que créer un seul package soit une bonne idée, cela n'est pas toujours possible. Si vous décidez de créer plusieurs packages, vous devez déterminer la segmentation du code de l'application. La présente section répertorie une liste de critères à utiliser pour planifier la création d'un package.

Bon nombre des critères de création d'un package ont des éléments en commun. Satisfaire à tous les critères de manière égale est souvent difficile. Ces critères sont présentés par ordre d'importance. Toutefois, cet ordre n'est qu'indicatif et peut être adapté à chaque circonstance. Bien que chaque critère soit important, leur optimisation afin de produire un ensemble de packages de qualité vous revient.

Pour voir d'autres idées de conception, reportez-vous au Chapitre 6, Techniques avancées de création de packages.

Packages pouvant être installés à distance

Tous les packages doivent pouvoir être installés à distance. Pouvoir être installé à distance signifie que l'administrateur chargé d'installer votre package a la possibilité de tenter son installation sur un système client et non pas nécessairement sur le système de fichiers root (/) sur lequel la commande pkgadd est exécutée.

Optimisation pour les configurations client-serveur

Prenez en compte les divers types de configurations logicielles système (par exemple, un système autonome et un serveur) lors de la création des packages. Une bonne conception de packages sépare les fichiers concernés afin d'optimiser l'installation de chaque type de configuration. Par exemple, le contenu des systèmes de fichiers root (/) et /usr doit être segmenté afin de pouvoir aisément prendre en charge les configurations serveur.

Package conçu d'après des limites fonctionnelles

Les packages doivent être autonomes et facilement identifiés d'après un groupe de fonctions. Par exemple, un package contenant UFS doit contenir toutes les fonctions UFS et être limité aux programmes binaires UFS.

Les packages doivent être organisés du point de vue du client en unités fonctionnelles.

Package en fonction des redevances

Placez le code requérant par contrat le versement d'une redevance dans un package ou groupe packages distinct. Ne répartissez pas le code dans des packages superflus.

Package en fonction des dépendances système

Placez les programmes binaires qui dépendent du système dans des packages distincts. Par exemple, le code du noyau doit être placé dans un package distinct, chaque architecture d'implémentation correspondant à un package différent. Cette règle s'applique également aux programmes binaires de diverses architectures. Par exemple, les programmes binaires d'un système SPARC peuvent être contenus dans un package et ceux d'un système x86, dans un autre.

Fonctions spécifiques à chaque package

Evitez autant que possible de créer des fichiers dupliqués lors de la création de vos packages. Toute duplication inutile se traduit par des problèmes de prise en charge et de version. Si votre produit se compose de plusieurs packages, comparez le contenu des packages régulièrement pour éviter de conserver des fichiers dupliqués.

Package en fonction de la localisation

Les éléments spécifiques à la localisation doivent se trouver dans un package à part. Le modèle idéal de création de packages d'un produit à localiser se compose d'un package par environnement linguistique. Il arrive malheureusement que les limites organisationnelles entrent en conflit avec les critères des limites fonctionnelles et des limites du produit.

Les paramètres internationaux par défaut peuvent également être fournis dans un package distinct. Cette conception isole les fichiers concernés par des modifications à apporter au niveau de la localisation et standardise le format de livraison des packages de localisation.