Guía del desarrollador para la creación de paquetes de aplicaciones

Consideraciones antes de construir un paquete

Antes de construir un paquete, debe decidir si el producto consistirá en uno o más paquetes. Tenga en cuenta que muchos paquetes pequeños necesitan más tiempo para instalarse que un paquete grande. Aunque la creación de un único paquete es una buena idea, no siempre es posible hacerlo. Si decide construir más de un paquete, debe determinar cómo segmentar el código de la aplicación. Esta sección proporciona una lista de criterios que usar al planificar la construcción de un paquete.

Muchos de los criterios de creación de paquetes se presentan como alternativas entre ellos. La satisfacción de todos los requisitos por igual es a menudo difícil. Estos criterios se presentan en orden de importancia. Sin embargo, esta secuencia está pensada para que sirva como guía flexible, según las circunstancias. Aunque cada criterio es importante, depende de usted optimizar estos requisitos para producir un buen conjunto de paquetes.

Si desea conocer más ideas de diseño, consulte el Capítulo 6Técnicas avanzadas para la creación de paquetes.

Creación de paquetes de instalación remota

Todos los paquetes deben ser de instalación remota. Por instalación remota se entiende que el administrador puede intentar la instalación del paquete en un sistema cliente, no necesariamente en el sistema de archivos raíz (/) donde se ejecuta el comando pkgadd.

Optimización de configuraciones de cliente-servidor

Considere los diversos tipos de configuraciones del software del sistema (por ejemplo, servidor y sistema autónomo) al distribuir los paquetes. Un buen diseño de creación de paquetes divide los archivos afectados para optimizar la instalación de cada tipo de configuración. Por ejemplo el contenido de los sistemas de archivos raíz (/) y /usr se debe segmentar para que las configuraciones de servidor se puedan admitir fácilmente.

Paquetes por restricciones funcionales

Los paquetes deben ser autónomos e identificarse de forma distintiva con un conjunto de funciones. Por ejemplo, un paquete que contiene UFS debe contener todas las utilidades de UFS y limitarse solamente a los binarios UFS.

Los paquetes se deben organizar desde el punto de vista del cliente en unidades funcionales.

Paquete con restricciones por derechos de autor

Coloque el código que precise el pago de derechos de autor debido a acuerdos contractuales en un paquete o grupo de paquetes específico. No disperse el código en más paquetes de los necesarios.

Paquete por dependencias del sistema

Conserve los binarios dependientes del sistema en paquetes dedicados. Por ejemplo, el código del núcleo debe estar en un paquete específico, con cada arquitectura de implementación constituida por una instancia de paquete distinta. Esta regla también se aplica a binarios para arquitecturas diferentes. Por ejemplo, los binarios para un sistema SPARC estarían en un paquete y los binarios para un sistema x86 estarían en otro.

Supresión de la superposición en los paquetes

Al construir los paquetes, suprima los archivos duplicados siempre que sea posible. La duplicación innecesaria de archivos provoca dificultades con las versiones y la asistencia técnica. Si el producto tiene varios paquetes, compare varias veces su contenido para buscar los archivos duplicados.

Paquete con restricciones en la ubicación

Los elementos específicos de la localización deben estar en su propio paquete. Un modelo de creación de paquetes ideal tendría las localizaciones de un producto distribuidas como un paquete por cada configuración regional. Desafortunadamente, en algunos casos, las restricciones organizativas entran en conflicto con los criterios de restricciones de productos y funcionales.

Los valores predeterminados internacionales también se pueden entregar en un paquete. Este diseño aísla los archivos que son necesarios para los cambios en la localización y estandariza el formato de distribución de los paquetes de localización.