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

Packages réadressables

L'ABI du System V suggère que le premier objectif d'un package réadressable était de simplifier l'installation du package pour l'administrateur. De nos jours, la nécessité des packages réadressables va plus loin. Il n'est plus seulement question de commodité puisqu'il arrive souvent lors de l'installation qu'un produit logiciel actif se trouve déjà dans le répertoire par défaut. Un package non conçu dans l'optique de gérer cette situation peut soit remplacer le produit existant, soit suspendre l'installation. Par contre, un package conçu pour gérer plusieurs architectures et plusieurs versions peut procéder à l'installation correctement et offrir à l'administrateur diverses options entièrement compatibles avec les habitudes d'administration déjà en place.

D'une certaine manière, le problème lié à l'existence de plusieurs architectures et celui lié à plusieurs versions est le même. Il faut pouvoir installer une variante du package actuel parallèlement à d'autres variantes et pouvoir diriger les clients ou les utilisateurs de systèmes autonomes de fichiers exportés vers n'importe laquelle de ces variantes sans y perdre en fonctionnalité. Bien que Sun ait établi des méthodes permettant de gérer plusieurs architectures sur un serveur, les administrateurs ne se conforment pas toujours à ces recommandations. Tous les packages doivent pouvoir se conformer aux souhaits raisonnables des administrateurs en matière d'installation.