Empaquetado de software para la instalación

Este tema proporciona información sobre la preparación de aplicaciones para ser instaladas con el comando installp.

En esta sección se describe el formato y el contenido del paquete de instalación del producto de software que debe proporcionar el desarrollador del producto. Ofrece una descripción de los archivos necesarios y opcionales que forman parte de un paquete de instalación o actualización de software.

Un paquete de instalación de un producto de software es un archivo con formato de copia de seguridad que contiene los archivos del producto de software, los archivos de control de instalación necesarios y los archivos de personalización de instalación opcionales. El comando installp se utiliza para instalar y actualizar productos de software.

Un paquete de instalación contiene una o varias unidades que se pueden instalar por separado, agrupadas lógicamente y denominadas conjuntos de archivos. Cada conjunto de archivos de un paquete debe pertenecer al mismo producto.

Un " actualización del conjunto de archivos o un " paquete de actualización es un paquete que contiene modificaciones de un conjunto de archivos existente.

A lo largo de este tema, el término sistema estándar se utiliza para referirse a un sistema que no está configurado como sistema sin disco.

Requisitos del procedimiento de instalación

• La instalación no debe requerir la interacción del usuario. La configuración del producto que requiere la interacción del usuario debe producirse antes o después de la instalación.
• Todas las instalaciones de conjuntos de archivos independientes o actualizaciones de conjuntos de archivos interdependientes deben poder realizarse durante una sola instalación.
• No debería ser necesario reiniciar el sistema para la instalación. La instalación detendrá partes del sistema relacionadas con la instalación, y es necesario reiniciar el sistema después de la instalación para que ésta surta pleno efecto.

Requisitos de información sobre el control de los envases

La información de control de paquetes debe:

• Especifique todos los requisitos de instalación que los filesets tienen sobre otros filesets.
• Especifique todos los requisitos de tamaño del sistema de archivos para la instalación del conjunto de archivos.

Formato de un paquete informático

Un paquete de instalación o actualización debe ser un único archivo en formato de copia de seguridad que pueda restaurarse mediante el comando installp durante la instalación. Este archivo se puede distribuir en cinta, disquete o CD-ROM.

Requisitos de partición de paquetes

Para soportar estaciones de trabajo cliente sin disco o sin datos, las partes del paquete específicas de la máquina (la parte raíz) deben estar separadas de las partes del paquete compartibles por la máquina (la parte usr). La parte usr del paquete contiene archivos que residen en el sistema de archivos ' /usr o ' /opt.

La instalación de la parte raíz del paquete no debe modificar ningún archivo del sistema de archivos /usr. El sistema de archivos /usr no es escribible durante la instalación de la parte raíz de un sistema cliente sin disco o sin datos. The machine–specific (root) part should include everything that is not in the /usr or /opt file systems.

Embalaje para particiones de carga de trabajo

Algunos productos de software requieren una consideración especial cuando se empaquetan para el particionamiento de carga de trabajo (WPAR). Para que un producto de software se despliegue correctamente en un WPAR, debe empaquetarse de forma que no intente escribir en los sistemas de archivos /usr o /opt durante la parte raíz del proceso, ya que un WPAR monta esos sistemas de archivos en modo de sólo lectura. Del mismo modo, cualquier configuración que deba realizarse en cada sistema donde se instale el producto debe realizarse desde la parte raíz del paquete.

Si no está previsto que un conjunto de archivos se instale nunca en una partición de carga de trabajo, debe designarse con el atributo PRIVATE en el archivo lpp_name del paquete.

Si un conjunto de archivos debe configurarse de forma diferente cuando se instala dentro de una WPAR, un script de empaquetado comprueba la variable de entorno INUWPAR para determinar si el conjunto de archivos se está instalando dentro de una WPAR.

Si un conjunto de archivos se configura de forma diferente cuando se instala en un WPAR, se reconfigurará cuando se cree un WPAR a partir de una copia del sistema, porque el conjunto de archivos no se instaló originalmente en un WPAR. Los propietarios de conjuntos de archivos pueden crear programas en los directorios ' /usr/lib/wpars/wparconvert.d/usr y ' /usr/lib/wpars/wparconvert.d/root ', que se ejecutarán al convertir las partes usr y root de su conjunto de archivos para que se ejecuten dentro de un WPAR de copia del sistema. Todos los archivos ejecutables dentro de esos directorios se ejecutan en orden alfabético (entorno local C) cuando se inicia por primera vez una WPAR de copia del sistema.

Datos vitales del producto de software

La información sobre un producto de software y sus opciones instalables se mantiene en la base de datos SWVPD (Software Vital Product Data). SWVPD consta de un conjunto de mandatos y las clases de objeto de Object Data Manager (ODM) para el mantenimiento de la información del producto de software. Los comandos SWVPD se proporcionan para que el usuario consulte(lslpp) y verifique(lppchk) los productos de software instalados. Las clases de objetos ODM definen el ámbito y el formato de la información del producto de software que se mantiene.

El comando installp utiliza el Gestor de Datos de Objetos para mantener la siguiente información en la base de datos SWVPD:

• El nombre del producto de software (por ejemplo, bos.adt)
• La versión del producto de software
• El nivel de release del producto de software, que indica cambios en la interfaz de programación externa del producto de software
• El nivel de modificación del producto de software, que indica los cambios que no afectan a la interfaz externa del producto de software
• El nivel de corrección del producto de software, que indica pequeñas actualizaciones que se incorporarán a un nivel de modificación regular más adelante
• El nombre, la suma de comprobación y el tamaño de los archivos que componen el producto o la opción de software
• El estado del producto de software: disponible, aplicando, aplicado, confirmando, comprometido, rechazando o roto
• Nivel de tecnología e información de APAR
• El directorio de destino y el instalador para el software empaquetado no installp, cuando sea aplicable.

Piezas de embalaje de productos de software

Ejemplo de guía del sistema de archivos para la partición de paquetes

A continuación se describen brevemente los sistemas de archivos y directorios. Puede utilizar esto como guía para dividir un paquete de producto en raíz, usr y compartir partes.

Algunos directorios de partes raíz y su contenido:

/dev

Archivos de dispositivo de máquina local

/etc

Archivos de configuración de la máquina como hosts y passwd

/sbin

Programas de utilidad del sistema necesarios para arrancar el sistema

/var

Archivos de datos y archivos de registro específicos del sistema

Algunos directorios de la parte usr y su contenido incluyen:

/usr/bin

Mandatos y scripts (ejecutables ordinarios)

/usr/sbin

Mandatos de administración del sistema

/usr/include

Archivos de inclusión

/usr/lib

Bibliotecas, mandatos no de usuario y datos dependientes de la arquitectura

/opt

Bibliotecas, comandos no de usuario y scripts asociados normalmente a productos que no son sistemas operativos.

Convenciones de nomenclatura de paquetes y conjuntos de archivos

Consideraciones especiales sobre la denominación de los paquetes de controladores de dispositivos

devices.BusTypeID.CardID.Extension

Por ejemplo, supongamos que un dispositivo ethernet se conecta al bus PCI y es identificado por el gestor de configuración con un identificador de tarjeta único de1410bb02. El paquete de filesets asociado a este dispositivo ethernet se llamaría devices.pci.1410bb02. El conjunto de archivos de entorno de ejecución dentro de este paquete se llamaría devices.pci.1410bb02.rte.

Consideraciones especiales sobre la nomenclatura de los catálogos de mensajes

Product.msg.Language.SubProduct

El sufijo opcional.SubProducto se utiliza cuando un producto tiene varios conjuntos de archivos de catálogo de mensajes para el mismo idioma, cada conjunto de archivos de catálogo de mensajes se aplica a un SubProduct diferente. Puede elegir tener un conjunto de archivos de mensajes para todo un producto.

Por ejemplo,Super_Widgetproducto tiene unplasticy unmetalconjunto de opciones de fileset. TodosSuper_WidgetLos catálogos de mensajes en inglés de EE.UU. pueden empaquetarse en un único conjunto de archivos denominadoSuper_Widget.msg.en_US. Si se necesitan conjuntos de archivos de catálogo de mensajes separados para elplasticymetallos conjuntos de archivos del catálogo de mensajes de EE.UU. en inglés se denominaríanSuper_Widget.msg.en_US.plasticySuper_Widget.msg.en_US.metal.

Nombres de archivo

Los archivos entregados con el paquete de software no pueden tener nombres que contengan comas o dos puntos. Las comas y los dos puntos se utilizan como delimitadores en los archivos de control utilizados durante el proceso de instalación de software. Los nombres de archivo pueden contener caracteres no ASCII. La vía de acceso completa para el nombre de archivo no puede tener más de 128 caracteres.

Identificación del nivel de revisión del juego de ficheros

Version.Release.Modification.FixLevel

Un nivel de instalación base de un fileset es el nivel de instalación inicial completo de un fileset. Este nivel contiene todos los archivos del conjunto de archivos, en lugar de una actualización de conjunto de archivos, que puede contener un subconjunto de archivos del conjunto de archivos completo.

Todos los filesets de un paquete de software deben tener el mismo nivel de fileset, aunque no es necesario para los paquetes con formato ' AIX® 4.1'.

Para todos los niveles nuevos de un conjunto de archivos, el nivel de conjunto de archivos debe aumentar. El comando installp utiliza el nivel del fileset para comprobar si existe un nivel posterior del producto en instalaciones posteriores.

el nivel de precedencia del conjunto de ficheros se lee de izquierda a derecha (por ejemplo,5.2.0.0es un nivel más nuevo que4.3.0.0).

Contenido de un paquete de software

Esta sección describe los archivos que contiene un paquete de instalación o actualización. Los nombres de vía de acceso de archivo se proporcionan para los tipos de paquete de instalación. En el caso de los paquetes de actualización, siempre que " PackageName " forme parte del nombre de la ruta, se sustituirá por " Nombre del paquete "/ "FilesetName "/" "FilesetLevel.

Ejemplo de contenido de un paquete de software

/usr/bin/raisehog (in the usr part of the package)
/usr/sbin/sellhog
 (in the usr part of the package)

/etc/hog
 (in the root part of the package)

./lpp_name
./usr/lpp/farm.apps/liblpp.a
./usr/lpp/farm.apps/inst_root/liblpp.a
./usr/bin/raisehog
./usr/sbin/sellhog
./usr/lpp/farm.apps/inst_root/etc/hog

/usr/sbin/sellhog
/etc/hog

./lpp_name
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/liblpp.a
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/liblpp.a
./usr/sbin/sellhog
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/etc/hog

El archivo de información del paquete lpp_name

Cada paquete de software debe contener el archivo de información del paquete lpp_name. El archivo lpp_name proporciona al comando installp información sobre el paquete y cada conjunto de archivos del paquete. Consulte la figura para ver un ejemplo de archivo lpp_name para un paquete de actualización de conjuntos de archivos. Los números y flechas de la figura hacen referencia a los campos que se describen en la tabla siguiente.

1 23    4
| ||    |                6         7 8 9  10       11
4 RSfarm.apps {  |       |         | | |   |        |
 5--> farm.apps.hog04.01.0000.0003 1 N U en_US Hog Utilities 
12--># ...      
[
13--> *ifreq bos.farming.rte (4.2.0.0) 4.2.0.15
%
14--> /usr/sbin 48
14--> /usr/lpp/farm.apps/farm.apps.hog/4.1.0.3 280
14--> /usr/lpp/farm.apps/farm.apps.hog/inst_root/4.1.0.3.96
14--> /usr/lpp/SAVESPACE 48
14--> /lpp/SAVESPACE 32
14--> /usr/lpp/bos.hos/farm.apps.hog/inst_root/4.1.0.3/ etc 32
%
%
15--> ranch.hog 4.1.0.0
%
16--> IX51366 Hogs producing eggs.
16--> IX81360 Piglets have too many ears.
]
}

Sección de información necesaria

La sección de información de requisito contiene información sobre las dependencias de instalación en otros conjuntos de archivos o actualizaciones de conjuntos de archivos. Cada requisito listado en la sección de requisito debe cumplirse de acuerdo con las reglas de requisito para poder aplicar el catálogo de archivos o la actualización de catálogo de archivos.

Antes de que se produzca cualquier instalación o actualización, el comando installp compara el estado actual de los conjuntos de archivos que se van a instalar con los requisitos enumerados en el archivo lpp_name. Si se ha especificado el indicador -g con la orden installp, los requisitos que falten se añadirán a la lista de conjuntos de archivos que deben instalarse. Los catálogos de archivos se ordenan para la instalación de acuerdo con los requisitos previos. Inmediatamente antes de instalar un conjunto de archivos, el comando installp comprueba de nuevo los requisitos para ese conjunto de archivos. Esta comprobación verifica que todos los requisitos instalados anteriormente en el proceso de instalación se han instalado correctamente y que se cumplen todos los requisitos.

En las siguientes descripciones de los distintos tipos de requisitos, RequiredFilesetLevel representa el nivel mínimo del conjunto de archivos que satisface los requisitos. Excepto cuando se bloquea explícitamente por las razones descritas en Sección de información de reemplazo, los niveles más recientes de un conjunto de archivos cumplen los requisitos en un nivel anterior. Por ejemplo, un requisito en elplum.tree 2.2.0.0se satisface con elplum.tree 3.1.0.0fileset.

Requisito previo

Un requisito previo indica que el conjunto de archivos especificado debe estar instalado en el nivel de conjunto de archivos especificado o en un nivel superior para que el conjunto de archivos actual pueda instalarse correctamente. Si se ha programado la instalación de un conjunto de archivos de prerrequisito, el comando installp ordena la lista de conjuntos de archivos a instalar para asegurarse de que se cumple el prerrequisito. No se garantiza un requisito previo en un conjunto de archivos dentro del mismo paquete.

*prereq Fileset RequiredFilesetLevel

Fileset RequiredFilesetLevel

Una actualización de conjunto de archivos contiene un requisito previo implícito para su conjunto de archivos de nivel base. Si este requisito previo implícito no es adecuado, debe especificar explícitamente un requisito previo diferente. La Versión y el Release de la actualización y el requisito previo implícito son los mismos. Si el FixLevel de la actualización es0el ModificationLevel y el FixLevel del prerrequisito implícito son ambos0. En caso contrario, el prerrequisito implícito tiene un ModificationLevel igual al ModificationLevel de la actualización y un FixLevel de0. Por ejemplo, una actualización de nivel 4.1.3.2 requiere que su nivel 4.1.3.0 esté instalado antes de la instalación de la actualización. Una actualización de nivel ' 4.1.3.0 ' requiere que su nivel ' 4.1.0.0 ' esté instalado antes de la instalación de la actualización.

Correquisito

Un correquisito indica que el conjunto de archivos especificado debe estar instalado para que el conjunto de archivos actual funcione correctamente. Al final del proceso de instalación, el comando installp emite mensajes de advertencia para cualquier requisito básico que no se cumpla. Se puede utilizar un correquisito para indicar requisitos entre conjuntos de archivos dentro del mismo paquete.

*coreq Fileset RequiredFilesetLevel

Si es necesario

*ifreq plum.tree (1.1.0.0) 1.1.2.3

*ifreq Fileset [(InstalledFilesetLevel)] RequiredFilesetLevel

Siplum.treeno está ya instalado, este ejemplo no hace que se instale. Siplum.treeya está instalado en cualquiera de los siguientes niveles, este ejemplo no provoca que el1.1.2.3nivel a instalar:

1.1.2.3

Este nivel coincide con el RequiredFilesetLevel.

1.2.0.0

Este nivel es un nivel de conjunto de archivos base diferente.

1.1.3.0

Este nivel sustituye RequiredFilesetLevel.

Siplum.treeya está instalado en cualquiera de los siguientes niveles, este ejemplo hace que el archivo1.1.2.3nivel a instalar:

1.1.0.0

Este nivel coincide con el InstalledFilesetLevel.

1.1.2.0

Este nivel es el mismo nivel base que el InstalledFilesetLevel y un nivel inferior al RequiredFilesetLevel.

El parámetroInstalledFilesetLevel) es opcional. Si se omite, se supone que la versión y la versión de theInstalledFilesetLevel y RequiredFilesetLevel son iguales. Si el FixLevel del RequiredFilesetLevel es0el ModificationLevel y el FixLevel del InstalledFilesetLevel son ambos0. En caso contrario, el InstalledFilesetLevel tiene un ModificationLevel que es el mismo que el ModificationLevel del RequiredFilesetLevel y un FixLevel de0. Por ejemplo, si el RequiredFilesetLevel es4.1.1.1y no se proporciona el parámetro InstalledFilesetLevel, el InstalledFilesetLevel es4.1.1.0. Si el RequiredFilesetLevel es4.1.1.0y no se proporciona el parámetro InstalledFilesetLevel, el InstalledFilesetLevel es4.1.0.0.

Requisito instalado

Un requisito de instalación indica que el conjunto de archivos especificado debe instalarse automáticamente sólo si su conjunto de archivos correspondiente ya está instalado o se encuentra en la lista de conjuntos de archivos que deben instalarse. También se instala un requisito instalado si el usuario solicita explícitamente que se instale. Una actualización de fileset no puede tener un requisito instalado. Dado que un conjunto de archivos que contiene los archivos de mensajes para un paquete concreto no debe instalarse automáticamente sin que se instale alguna otra parte del paquete, un conjunto de archivos de mensajes siempre debe contener un requisito instalado para otro conjunto de archivos de su producto.

*instreq Fileset RequiredFilesetLevel

Requisito de grupo

Un requisito de grupo indica que diferentes condiciones de requisito pueden satisfacer el requisito. Un requisito de grupo puede contener requisitos previos, correquisitos, requisitos if y requisitos de grupo anidados. El número que precede a { RequisiteExpressionList } identifica cuántos de los elementos de RequisiteExpressionList son necesarios. Por ejemplo,>2establece que se necesitan al menos tres elementos de la RequisiteExpressionList.

>Number { RequisiteExpressionList }

Ejemplos de secciones de información necesaria

1. El ejemplo siguiente ilustra el uso de correquisitos. Los 2book.create 12.30.0.0no puede funcionar sinlayout.text 1.1.0.0yindex.generate 2.3.0.0instalados, por lo que la sección necesaria parabook.create 12.30.0.0contiene:

   *coreq layout.text 1.1.0.0
   *coreq index.generate 2.3.0.0

   Los 2index.generate 3.1.0.0satisface los criteriosindex.generaterequisito, porque3.1.0.0es un nivel más nuevo que el requerido2.3.0.0nivel.
2. El ejemplo siguiente ilustra el uso de los tipos de requisito más comunes. conjunto de archivosnew.fileset.rte 1.1.0.0contiene los siguientes requisitos:

   *prereq database.rte 1.2.0.0
   *coreq spreadsheet.rte 1.3.1.0
   *ifreq wordprocessorA.rte (4.1.0.0) 4.1.1.1
   *ifreq wordprocessorB.rte 4.1.1.1

   Los 2database.rtedebe instalarse en el nivel1.2.0.0o superior antes delnew.fileset.rtepuede instalarse. Sidatabase.rteynew.fileset.rtese instalan en la misma sesión de instalación, el programa de instalación instala eldatabaseantes delnew.fileset.rtefileset.

   Los 2spreadsheet.rtedebe instalarse en el nivel1.3.1.0o superior para elnew.fileset.rtepara que funcione correctamente. Los 2spreadsheet.rteno necesita estar instalado antes de que elnew.fileset.rtesiempre que ambos se instalen en la misma sesión de instalación. Si un nivel adecuado delspreadsheet.rteno se ha instalado al final de la sesión de instalación, se emitirá un mensaje de advertencia indicando que no se cumple el requisito básico.

   SiwordprocessorA.rteestá instalado (o se está instalando connew.fileset.rte) en el nivel4.1.0.0entonces elwordprocessorA.rtefileset update debe instalarse en el nivel4.1.1.1o superior.

   SiwordprocessorB.rteestá instalado (o se está instalando connew.fileset.rte) en el nivel4.1.1.0entonces elwordprocessorB.rtefileset update debe instalarse en el nivel4.1.1.1o superior.

3. El ejemplo siguiente ilustra un requisito instalado. conjunto de archivosSuper.msg.fr_FR.Widgeta nivel2.1.0.0contiene el siguiente requisito de instalación:

   *instreq Super.Widget 2.1.0.0

   Los 2Super.msg.fr_FR.Widgetno puede instalarse automáticamente cuandoSuper.Widgetno está instalado. Los 2Super.msg.fr_FR.Widgetpuede instalarse cuando elSuper.Widgetno se instala si el fileset aparece explícitamente en la lista de filesets a instalar..

4. El ejemplo siguiente ilustra un requisito de grupo. Debe estar instalado al menos uno de los conjuntos de archivos de requisitos previos enumerados (pueden estar instalados ambos). Si está instalado, elspreadsheet_1.rtedebe estar en el nivel1.2.0.0o superior o elspreadsheet_2.rtedebe estar en el nivel1.3.0.0o superior.

   >0 {
   *prereq spreadsheet_1.rte 1.2.0.0
   *prereq spreadsheet_2.rte 1.3.0.0
   }

Información sobre el tamaño y el acuerdo de licencia

La sección de información sobre el tamaño y el acuerdo de licencia contiene información sobre el espacio de disco y los requisitos del acuerdo de licencia para el conjunto de archivos.

información de tamaño

Directory PermanentSpace [TemporarySpace]

Además, el desarrollador del producto puede especificar PAGESPACE o INSTWORK en el campo del nombre de la ruta completa para indicar los requisitos de espacio en disco para el espacio de paginación y el espacio de trabajo necesarios en el directorio del paquete durante el proceso de instalación.

Directorio

El nombre completo de la vía de acceso del directorio que tiene requisitos de tamaño.

PermanentSpace

El tamaño (en bloques de 512 bytes) del espacio permanente necesario para la instalación o actualización. El espacio permanente es el espacio que se necesita una vez finalizada la instalación. Este campo tiene un significado diferente en los siguientes casos:

Si Directory es PAGESPACE, PermanentSpace representa el tamaño del espacio de página necesario (en bloques de 512 bytes) para realizar la instalación.

Si Directorio es INSTWORK, PermanentSpace representa el número de bloques de 512 bytes necesarios para extraer los archivos de control utilizados durante la instalación. Estos archivos de control son los archivos que se archivan en el archivo liblpp.a.

TemporarySpace

El tamaño (en bloques de 512 bytes) del espacio temporal necesario sólo para la instalación. El espacio temporal se libera una vez finalizada la instalación. El valor de TemporarySpace es opcional. Un ejemplo de espacio temporal es el necesario para volver a vincular un archivo objeto ejecutable. Otro ejemplo es el espacio necesario para archivar un fichero de objetos en una biblioteca. Para archivar en una biblioteca, el comando installp hace una copia de la biblioteca, archiva el fichero objeto en la biblioteca copiada y mueve la biblioteca copiada sobre la biblioteca original. El espacio para la copia de la biblioteca se considera espacio temporal.

Cuando Directory es INSTWORK, TemporarySpace representa el número de bloques de 512 bytes necesarios para el archivo liblpp.a sin extraer.

/usr/bin          30
/lib              40  20
PAGESPACE         10
INSTWORK          10    6

Dado que es difícil predecir cómo se montan los sistemas de archivos de disco en el árbol de archivos, las entradas de nombre de ruta de directorio en la sección de información de tamaño deben ser lo más específicas posible. Por ejemplo, es mejor tener una entrada para /usr/bin y otra para /usr/lib que tener una entrada combinada para /usr, porque /usr/bin y /usr/lib pueden existir en diferentes sistemas de ficheros que estén ambos montados bajo /usr. En general, es mejor incluir entradas para cada directorio en el que se instalan los archivos.

Sólo para un paquete de actualización, la información sobre el tamaño debe incluir todos los archivos antiguos (que se sustituirán) que se moverán a los directorios guardados. Estos archivos antiguos se restaurarán si la actualización se rechaza posteriormente. Para indicar estos requisitos de tamaño, un paquete de actualización debe especificar los siguientes directorios especiales:

/usr/lpp/SAVESPACE

El directorio donde se guardan los archivos de las partes usr. Por defecto, los archivos de partes usr se guardan en el directorio ' /usr/lpp/ 'Nombre del paquete '/ 'FilesetName/FilesetLevel '.guardar.

/lpp/SAVESPACE

El directorio para guardar los archivos de la parte raíz. Por defecto, los archivos de la parte raíz se guardan en el directorio ' /lpp/ 'Nombre del paquete '/ 'FilesetName/FilesetLevel '.guardar.

Información sobre el acuerdo de licencia

Una reciente adición al proceso de instalación de AIX permite a los propietarios de productos exigir que el cliente firme un acuerdo de licencia antes de instalar el producto. El comando ' installp ' lee el archivo lpp_name de un fileset como es habitual para cualquier imagen. Si hay entradas ' LAF o ' LAR ' en la sección de tamaño del archivo lpp_name, el comando ' installp ' llama al comando ' inulag ' que muestra la licencia en una ventana y registra la aceptación de la licencia por parte del cliente. Si el cliente se niega a aceptar la licencia, la instalación se detiene para ese producto.

Dónde colocar el archivo de licencia

La colocación de los archivos de licencia depende del propietario del producto. No obstante, se recomienda encarecidamente que la licencia se coloque en " /usr/swlag/LANG. El nombre sugerido para el archivo del Acuerdo de Licencia es ' ProductName_VersionRelease.la. No hay ningún requisito para utilizar este nombre o ubicación. El comando " installp " y este envoltorio es simplemente el suministro de un método para entregar la información a los clientes. El producto debe proporcionar todas las herramientas y el contenido del archivo.

Requisitos de traducción del archivo de licencia

Si es necesario traducir los archivos del Acuerdo de licencia a los idiomas admitidos, se recomienda separar los archivos por idioma. Esta traducción puede requerir que se creen varios archivos.

Cómo enviar el archivo de licencia

Un producto puede enviar el archivo de licencia como parte de su producto principal o en un conjunto de archivos independiente para el producto. Muchos productos están eligiendo crear un conjunto de archivos separado para enviar sólo los archivos de licencia. Esto permite a un producto con muchas funciones diferentes crear un archivo de licencia y un conjunto de archivos que pueden enviarse en todos los soportes necesarios para cada función, en lugar de tener que incluir los archivos en varias funciones diferentes. Las sugerencias actuales para el nombre del conjunto de archivos son lpp.license o lpp.loc.license. La mayoría de los productos están utilizando actualmente la primera sugerencia. Si desea que el conjunto de archivos de licencia se oculte al cliente en las instalaciones estándar, utilice lpp.loc.license porque no es necesario seleccionar el conjunto de archivos de licencia para la instalación.

Cómo empaquetar el archivo de licencia

Ejemplo de conjunto de archivos LAF

iced.tea.loc.license 03.01.0000.0000 1 N U en_US IcedTea Recipe License Information
[
%
INSTWORK 16 160
LAF/usr/swlag/de_DE/iced.tea.la 24
LAF/usr/swlag/DE_DE/iced.tea.la 24
LAF/usr/swlag/en_US/iced.tea.la 24
LAF/usr/swlag/EN_US/iced.tea.la 24
LAF/usr/swlag/es_ES/iced.tea.la 24
LAF/usr/swlag/ES_ES/iced.tea.la 24
LAF/usr/swlag/fr_FR/iced.tea.la 24
LAF/usr/swlag/FR_FR/iced.tea.la 24
LAF/usr/swlag/it_IT/iced.tea.la 24
LAF/usr/swlag/IT_IT/iced.tea.la 24
LAF/usr/swlag/ja_JP/iced.tea.la 24
LAF/usr/swlag/JA_JP/iced.tea.la 32
LAF/usr/swlag/Ja_JP/iced.tea.la 24
LAF/usr/swlag/ko_KR/iced.tea.la 24
LAF/usr/swlag/KO_KR/iced.tea.la 24
LAF/usr/swlag/pt_BR/iced.tea.la 24
LAF/usr/swlag/PT_BR/iced.tea.la 24
LAF/usr/swlag/ru_RU/iced.tea.la 24
LAF/usr/swlag/RU_RU/iced.tea.la 48
LAF/usr/swlag/zh_CN/iced.tea.la 16
LAF/usr/swlag/zh_TW/iced.tea.la 16
LAF/usr/swlag/Zh_TW/iced.tea.la 16
LAF/usr/swlag/ZH_TW/iced.tea.la 24
%
%
%
]

LAR Fileset ejemplo

iced.tea.server 03.01.0000.0010 1 N B en_US Iced Tea Recipe Group
[
*prereq bos.net.tcp.client 5.1.0.10
*coreq iced.tea.tools 5.1.0.10
*coreq Java14.sdk 1.4.0.1
%
/usr/bin 624
/usr/lib/objrepos 24
/usr/include 16
/usr/include/sys 56
/usr/lpp/iced.tea 22
/usr/samples/iced.tea 8
/usr/samples/iced.tea/server 504
/usr/lpp/iced.tea/inst_root/etc/tea 8
/usr/iced.tea 8
/usr/lpp/iced.tea/inst_root/etc/tea/Top 8
INSTWORK 208 96
/lpp/iced.tea 104
/etc/tea 8
/etc/objrepos 8
/etc/tea/Top 8
/tmp 0 6
LAR/usr/swlag/%L/iced.tea.la 0
%
%
%
]

Sustituye a la sección de información

La sección de información de sustitución indica los niveles de un fileset o actualización de fileset para los que este fileset o actualización de fileset puede (o no) utilizarse como sustitución. La información de reemplazo es opcional y solo es aplicable a los paquetes de instalación base de catálogo de archivos con formato AIX 4.1y a los paquetes de actualización de catálogo de archivos con formato AIX 3.2.

Un conjunto de archivos más reciente sustituye a cualquier versión anterior de ese conjunto de archivos a menos que la sección supersedes del archivo lpp_name identifique el último nivel de ese conjunto de archivos al que sustituye. En los raros casos en los que un fileset no sustituye a todos los niveles anteriores de ese fileset, el comando installp no utiliza el fileset para satisfacer requisitos en niveles anteriores al nivel del fileset listado en la sección supersedes.

Una actualización de conjunto de archivos reemplaza una actualización más antigua para ese conjunto de archivos sólo si contiene todos los archivos, el proceso de configuración y la información necesaria contenida en la actualización de conjunto de archivos más antigua. El comando installp determina que una actualización de un fileset sustituye a otra actualización para ese fileset en las siguientes condiciones:

• Los niveles de versión, lanzamiento y modificación de las actualizaciones son iguales, los niveles de corrección son ambos distintos de cero y la actualización con el nivel de corrección más alto no contiene un requisito previo en un nivel del conjunto de archivos mayor o igual que el nivel de la actualización con el nivel de corrección más bajo.
• Los niveles de versión y lanzamiento de las actualizaciones son iguales, y la actualización con el nivel de modificación más alto no contiene un requisito previo en un nivel del conjunto de archivos mayor o igual que el nivel de la actualización con el nivel de modificación más bajo.

Por ejemplo, la actualización del conjunto de ficherosfarm.apps.hog 4.1.0.1ofrece una actualización de/usr/sbin/sellhog. Actualización del conjunto de archivosfarm.apps.hog 4.1.0.3envía actualizaciones al/usr/sbin/sellhogy el archivo/etc/hog.xlsx Actualización de catálogo de archivosfarm.apps.hog 4.1.1.2entrega una actualización del/usr/bin/raisehog.xlsx

Actualizarfarm.apps.hog 4.1.0.3Reemplazafarm.apps.hog 4.1.0.1porque entrega los mismos archivos y se aplica al mismo nivel,farm.apps.hog 4.1.0.0.

Actualizarfarm.apps.hog 4.1.1.2no sustituye afarm.apps.hog 4.1.0.3ofarm.apps.hog 4.1.0.1porque no contiene los mismos archivos y se aplica a un nivel diferente,farm.apps.hog 4.1.1.0. Actualizaciónfarm.apps.hog 4.1.1.0Reemplazafarm.apps.hog 4.1.0.1yfarm.apps.hog 4.1.0.3.

Sustituye a la sección de niveles de instalación de conjuntos de archivos (niveles base)

Un paquete de instalación de conjunto de archivos con formato AIX 4.1puede contener las siguientes entradas de reemplazo:

Entrada de barrera

Identifica el nivel de conjunto de archivos donde se introdujo una incompatibilidad importante. Esta incompatibilidad impide que el conjunto de archivos actual satisfaga los requisitos de los niveles del conjunto de archivos anteriores al nivel especificado.

Entrada de compatibilidad

Indica que el conjunto de archivos puede utilizarse para satisfacer los requisitos de otro conjunto de archivos. Se utiliza una entrada de compatibilidad cuando un conjunto de archivos se ha renombrado o ha quedado obsoleto. Sólo un conjunto de archivos puede reemplazar a un conjunto de archivos determinado. Puede especificar sólo una entrada de compatibilidad para cada conjunto de archivos.

El archivo lpp_name puede contener como máximo una barrera y una entrada de compatibilidad para un conjunto de archivos.

Una entrada de barrera consta del nombre del conjunto de archivos y el nivel del conjunto de archivos cuando se introdujo la incompatibilidad. Una entrada de barrera es necesaria para un conjunto de archivos sólo en el raro caso de que un nivel del conjunto de archivos haya introducido una incompatibilidad tal que la funcionalidad requerida por los conjuntos de archivos dependientes se haya modificado o eliminado hasta tal punto que no se cumplan los requisitos de los niveles anteriores del conjunto de archivos. Debe existir una entrada de barrera en todas las versiones posteriores del conjunto de archivos que indique el nivel más reciente del conjunto de archivos que satisface los requisitos de los conjuntos de archivos dependientes.

Por ejemplo, si se ha introducido una incompatibilidad importante en el conjunto de ficherosBad.Idea 6.5.6.0la sección de información de sustitución de cadaBad.Ideapaquete de instalación del fileset desde el nivel del fileset6.5.6.0en adelante contendría unBad.Idea 6.5.6.0barrera de entrada. Esta barrera de entrada impediría un requisito deBad.Idea 6.5.4.0de ser satisfecha por cualquier nivel deBad.Ideamayor o igual que6.5.6.0.

Una entrada de compatibilidad consta de un nombre de conjunto de archivos (diferente del conjunto de archivos del paquete) y un nivel de conjunto de archivos. El nivel de conjunto de archivos identifica el nivel en el que el conjunto de archivos del paquete de instalación cumple los requisitos para el conjunto de archivos especificado (y los niveles anteriores de dicho conjunto de archivos). La compatibilidad es útil cuando el conjunto de archivos especificado está obsoleto o se ha renombrado, y la función del conjunto de archivos especificado está contenida en el conjunto de archivos actual. El nivel del conjunto de archivos en la entrada de compatibilidad debe ser superior a cualquier nivel que se espere que exista para el conjunto de archivos especificado.

A modo de ejemplo, supongamos queYear.Full 19.91.0.0ya no se entrega como una unidad, sino que se divide en varios conjuntos de archivos individuales más pequeños. Sólo uno de los pequeños conjuntos de archivos resultantes, tal vezWinter 19.94.0.0debe contener una entrada de compatibilidad deYear.Full 19.94.0.0. Esta entrada de compatibilidad permiteWinter 19.94.0.0para satisfacer los requisitos de los conjuntos de archivos dependientes deYear.Fulla niveles19.94.0.0y anteriores.

Sustituye al tratamiento

El comando installp ofrece las siguientes funciones especiales para instalar conjuntos de archivos y actualizaciones de conjuntos de archivos que sustituyen a otros conjuntos de archivos o actualizaciones de conjuntos de archivos:

• Si el soporte de instalación no contiene un conjunto de archivos o una actualización de conjunto de archivos que el usuario ha solicitado instalar, se puede instalar un conjunto de archivos reemplazante o una actualización de conjunto de archivos en el soporte de instalación.

  Por ejemplo, supongamos que un usuario invoca el comando installp con el indicador -g (instalar automáticamente los requisitos) para instalar el archivofarm.apps.hog 4.1.0.2fileset. Si el soporte de instalación contiene elfarm.apps.hog 4.1.0.4el comando installp instalará el conjunto de archivosfarm.apps.hog 4.1.0.4porque sustituye al nivel solicitado.

• Si el sistema y el soporte de instalación no contienen un conjunto de archivos necesario o una actualización de conjunto de archivos, el requisito puede satisfacerse mediante una actualización de conjunto de archivos o de conjunto de archivos reemplazante.
• Si se solicita la instalación de una actualización y se especifica el indicador -g, la solicitud se satisface con la actualización más reciente del soporte de instalación.

  Cuando se especifica el indicador -g con el comando installp, cualquier actualización solicitada para la instalación (explícita o implícitamente) se satisface con la actualización más reciente del medio de instalación. Si el usuario desea instalar un nivel concreto de una actualización, no necesariamente el último, puede invocar el comandoinstallp sin el indicador -g.

• Si se solicita la instalación de una actualización y otra que la sustituye (ambas en el medio de instalación), el comando installp instala sólo la actualización más reciente.

  En este caso, si un usuario desea aplicar una actualización determinada y su actualización sustitutiva desde el soporte de instalación, deberá realizar operaciones de instalación separadas para cada nivel de actualización. Tenga en cuenta que este tipo de operación no tiene sentido si las dos actualizaciones se aplican y se confirman(-ac). La confirmación de la segunda actualización elimina la primera del sistema.

Corregir la sección de información

La sección de información de arreglos es opcional. Las entradas de sección de información de arreglo contienen una palabra clave de arreglo y una descripción de 60 caracteres o menos del problema arreglado. Una palabra clave de arreglo es un identificador de 16 caracteres o menos correspondiente al arreglo. Las palabras clave de fijación que empiezan por ' ix, ' iy, ' IY yIX están reservadas para su uso por el fabricante del sistema operativo.

Un nivel de tecnología es un arreglo que es un nivel de actualización principal. Los paquetes de mantenimiento preventivo periódico son niveles de tecnología. Un identificador de nivel tecnológico comienza con el nombre del producto de software (no del paquete), seguido de un único punto (.) y un nivel identificativo, como por ejemplofarm.4.1.1.0.

El archivo de la biblioteca de control de instalación liblpp.a

El fichero liblpp.a es un archivo que contiene los ficheros necesarios para controlar la instalación del paquete. Puede crear un archivo liblpp.a para su paquete utilizando el comando ar con el indicador -g en sistemas posteriores a AIX 4.3 para asegurarse de que se crea un archivo de 32 bits. Esta sección describe muchos de los archivos que puedes incluir en un archivo liblpp.a.

A lo largo de esta sección, Conjunto de archivos aparece en los nombres de los archivos de control. Conjunto de archivos representa el nombre del conjunto de archivos independiente que se va a instalar en el paquete de software. Por ejemplo, supongamos que el archivo de la lista de aplicaciones se describe como Fileset.al. El archivo de la lista de aplicaciones parabos.net.tcp.clientde labos.netproducto de software seríabos.net.tcp.client.al.

Muchos de los archivos descritos en esta sección son opcionales. Un archivo opcional sólo es necesario si la función que proporciona el archivo es necesaria para el conjunto de archivos o la actualización del conjunto de archivos. A menos que se indique lo contrario, un archivo pertenece tanto a paquetes de instalación completos como a paquetes de actualización de catálogos de archivos.

Archivos de datos contenidos en el archivo liblpp.a

Archivos ejecutables opcionales contenidos en el archivo liblpp.a

Los archivos ejecutables específicos del producto descritos en esta sección se ejecutan durante el proceso de instalación. A menos que se indique lo contrario, los nombres de archivo que terminan en _i sólo se utilizan durante el proceso de instalación, y los nombres de archivo que terminan en _u sólo se utilizan en el proceso de actualización del conjunto de archivos. Todos los archivos descritos en esta sección son opcionales y pueden ser scripts de shell o módulos de objetos ejecutables. Cada programa debe tener un valor de retorno de 0 (cero), a menos que el programa esté destinado a causar que la instalación o actualización falle.

'Conjunto de archivos.config o ' Conjunto de archivos.config_u

Modifica la configuración cerca del final del proceso de instalación o actualización predeterminado. Fileset. config sólo se utiliza durante el proceso de instalación.

Fileset.odmdel oFileset.*.odmdel

Actualiza la información de la base de datos ODM para el conjunto de archivos antes de añadir nuevas entradas ODM para el conjunto de archivos. Las convenciones de nomenclatura de archivos " odmdel " permiten que un conjunto de archivos tenga varios archivos " odmdel ".

Fileset.pre_d

Indica si un conjunto de archivos puede eliminarse durante la desinstalación. El programa debe devolver un valor de 0 (cero) si se puede eliminar el conjunto de archivos. Los conjuntos de archivos se pueden eliminar de forma predeterminada. El programa debería generar mensajes de error indicando por qué el conjunto de archivos no es extraíble.

'Conjunto de archivos.pre_i o ' Conjunto de archivos.pre_u

Se ejecuta antes de restaurar o guardar los archivos de la lista de aplicación en el paquete, pero después de eliminar los archivos de una versión previamente instalada del conjunto de archivos.

Fileset.pre_rej

Se ejecuta antes de la operación de rechazo o antes de la vista previa de una operación de rechazo del conjunto de archivos. Utilice el script para determinar si el conjunto de archivos se puede rechazar. No utilice este script para ejecutar ningún comando que cambie algo en el sistema. Si el script sale con un código de retorno distinto de cero, la operación de rechazo no está permitida.

Fileset.pre_rm

Se ejecuta durante la instalación de un fileset antes de eliminar los archivos de una versión previamente instalada del fileset.

'Conjunto de archivos.post_i o ' Conjunto de archivos.post_u

Se ejecuta después de restaurar los archivos de la lista de aplicación de la instalación o actualización del conjunto de archivos.

'Conjunto de archivos.unconfig ' Conjunto de archivos.unconfig_u

Deshace el procesamiento de configuración realizado en la instalación o actualización durante una desinstalación o un rechazo de un conjunto de archivos. Fileset.unconfig sólo se utiliza durante el proceso de desinstalación.

Fileset.unodmadd

Suprime las entradas que se han añadido a bases de datos ODM durante la instalación o actualización.

Fileset.unpost_i oFileset.unpost_u

Deshace el procesamiento realizado tras restaurar los archivos de la lista de aplicación en la instalación o actualización durante una desinstalación o un rechazo de un conjunto de archivos.

'Conjunto de archivos.unpre_i o ' Conjunto de archivos.unpre_u

Deshace el procesamiento realizado antes de restaurar los archivos de la lista de aplicación en la instalación o actualización durante una desinstalación o un rechazo de un conjunto de archivos.

Si alguno de estos archivos ejecutables ejecuta un comando que puede cambiar la configuración del dispositivo en una máquina, ese archivo ejecutable debe comprobar la variable de entorno INUCLIENTS antes de ejecutar el comando. Si la variable de entorno INUCLIENTS está activada, el comando no debe ejecutarse. El entorno de Gestión de Instalaciones en Red (NIM) utiliza el comando installp para muchos propósitos, algunos de los cuales requieren que el comando installp omita parte de su procesamiento normal. NIM establece la variable de entorno INUCLIENTS cuando se debe omitir este proceso normal.

Si el proceso de instalación por defecto es insuficiente para su paquete, puede proporcionar los siguientes archivos ejecutables en el archivo liblpp.a. Si el paquete incluye estos archivos, el comando installp utiliza los archivos proporcionados por el paquete en lugar de los archivos predeterminados del sistema. Los archivos proporcionados por el paquete deben contener la misma funcionalidad que los archivos predeterminados o pueden producirse resultados inesperados. Puede utilizar los archivos predeterminados como modelos para crear sus propios archivos. Se recomienda encarecidamente utilizar los archivos predeterminados en lugar de los archivos proporcionados por el paquete.

instale

Se utiliza en lugar del script de instalación por defecto /usr/lib/instl/instal. El comando installp llama a este archivo ejecutable si se aplica un conjunto de archivos de un paquete de instalación.

lpp.cleanup

Se utiliza en lugar del script de limpieza de la instalación por defecto /usr/lib/instl/cleanup. El comando installp llama a este archivo ejecutable si un conjunto de archivos de un paquete de instalación o actualización se ha aplicado parcialmente y debe limpiarse para devolver el conjunto de archivos a un estado coherente.

lpp.deinstal

Se utiliza en lugar del script de eliminación de conjuntos de archivos predeterminado /usr/lib/instl/deinstal. This executable file must be placed in the /usr/lpp/Nombre del paquete directory. El comando installp llama a este archivo ejecutable si se elimina un conjunto de archivos de un paquete de instalación.

lpp.reject

Se utiliza en lugar del script de rechazo de la instalación por defecto /usr/lib/instl/reject. El comando installp llama a este ejecutable si se rechaza la actualización de un fileset en un paquete de actualización. (El script por defecto ' /usr/lib/instl/reject ' es un enlace al script ' /usr/lib/instl/cleanup ')

actualización

Se utiliza en lugar del script de actualización por defecto /usr/lib/instl/update. El comando installp llama a este archivo ejecutable si se aplica un conjunto de archivos de un paquete de actualización. (El script por defecto ' /usr/lib/instl/update ' es un enlace al script ' /usr/lib/instl/instal ')

Archivo ejecutable opcional contenido en el archivo Fileset.al

Descripción detallada de los archivos de control de la instalacióneEl archivo " Fileset.cfgfiles

El archivo Fileset.cfgfiles enumera los archivos de configuración que deben guardarse para migrar a una nueva versión del fileset sin perder los datos configurados por el usuario. Para conservar los datos de configuración del usuario, se debe proporcionar un archivo Fileset.cfgfiles en el archivo liblpp.a adecuado (usr o root).

El Fileset.cfgfiles contiene una entrada de una línea para cada archivo que se va a guardar. Cada entrada contiene el nombre de archivo (un nombre de vía de acceso relativo a la raíz), un separador de espacios en blanco y una palabra clave que describe el método de manejo para la migración del archivo. Las palabras clave del método de manejo son:

Conservar

Sustituye la nueva versión instalada del archivo por la versión guardada en el directorio de almacenamiento. Después de sustituir el nuevo archivo por la versión guardada, se suprime el archivo guardado del directorio de guardado de configuración.

fusión_automática

Durante el procesamiento Fileset.post_i, los ejecutables proporcionados por el producto fusionan los datos necesarios de la nueva versión instalada del archivo en la versión anterior del archivo guardada en el directorio de almacenamiento de configuración. Tras el procesamiento de Fileset.post_i, el comando installp sustituye la nueva versión instalada del archivo por la versión fusionada en el directorio de guardado de la configuración (si existe) y, a continuación, elimina el archivo guardado.

nuevo_retención

Sustituye la nueva versión instalada del archivo por la versión guardada en el directorio de almacenamiento. La nueva versión del archivo se coloca en el directorio de guardado de configuración en lugar de la versión antigua. El usuario podrá hacer referencia a la nueva versión.

fusión_usuario

Deja la nueva versión instalada del archivo en el sistema y mantiene la versión antigua del archivo en el directorio de guardado de configuración. El usuario podrá hacer referencia a la versión antigua para realizar cualquier fusión que sea necesaria. Esta palabra clave debe evitarse en la medida de lo posible.

otros

Se utiliza en cualquier caso cuando ninguno de los otros métodos de manejo definidos son suficientes. El comando installp guarda el archivo en el directorio de guardado de configuración y no proporciona más ayuda. Cualquier otra manipulación y manejo del archivo de configuración debe ser realizado por los ejecutables proporcionados por el producto. El desarrollador del producto tiene la responsabilidad de documentar el manejo del archivo.

El ejecutable Fileset.post_i puede utilizarse para realizar manipulaciones o fusiones específicas de datos de configuración que no pueden realizarse mediante el procesamiento de instalación predeterminado.

Ficheros de configuración incluidos en el Fileset.los archivos cfgfiles se guardan en el directorio de almacenamiento de la configuración con el mismo nombre de ruta relativo que se indica en Fileset.archivo cfgfiles. El nombre del directorio para guardar la configuración se almacena en la variable de entorno MIGSAVE. El directorio de guardado corresponde a la parte del paquete que se está instalando. Los directorios siguientes son los directorios de salvar de configuración:

/usr/lpp/save.config

Para la parte usr

/lpp/save.config

Para la parte de la raíz

Si la lista de archivos que necesita guardar varía en función del nivel de instalación actual del conjunto de archivos, el archivo Fileset.cfgfiles debe contener toda la lista de archivos de configuración que puedan encontrarse. Si es necesario, el ejecutable Fileset.post_i (o los ejecutables proporcionados por otros productos) deben gestionar la diferencia.

Por ejemplo, suponga que tiene un conjunto de archivoschange.rte) que tiene un archivo que se puede configurar. Así, en la raíz change.rte.cfgfiles, hay un archivo en la lista:

/etc/change_user   user_merge

Al migrar de su antiguo conjunto de archivoschange.obj) a change.rte, no podrá conservar este archivo porque el formato ha cambiado. Sin embargo, al migrar de un change.rte de nivel más antiguo a un change.rte de nivel más reciente, el archivo puede conservarse. En este caso, es posible que desee crear un script change.rte.post_i que compruebe de qué conjunto de archivos está migrando y actúe en consecuencia. De esta forma, si un usuario ha realizado cambios en el archivo /etc/change_user, éstos se guardan.

#! /bin/ksh
rc=0
grep -q change.rte $INSTALLED_LIST
if [$? = 0]
then
mv $MIGSAVE/etc/change_user/ /etc/change_user
rc=1
fi
exit $rc

$INSTALLED_LIST es creada y exportada por installp. Consulte Instalación para archivos de control específicos para productos reempaquetados para obtener más información sobre el archivo de configuraciónFileset.installed_list. La variable $MIGSAVE contiene el nombre del directorio en el que se guardan los archivos de configuración de la parte raíz.

El comando installp no produce un mensaje de advertencia o error si no se encuentra un archivo listado en el archivo Fileset.cfgfiles. El comando installp tampoco produce un mensaje para un archivo que no se encuentra durante la fase que sigue al procesamiento Fileset.post_i cuando los archivos de configuración guardados se procesan según sus métodos de manejo. Si se desean mensajes de advertencia o error, los ejecutables proporcionados por el producto deben generar los mensajes.

./etc/cfg_leafpreserve
./etc/cfg_pudding hold_new
./etc/cfg_newtonpreserve

El archivo Fileset.fixdata

La información de este archivo se añade a una base de datos de arreglos. El comando instfix utiliza esta base de datos para identificar las correcciones instaladas en el sistema. Si el Fileset.fixdata existe en un paquete, la información del fix en la base de datos del fix se actualiza cuando se aplica el paquete.

Cada fix del fileset debe tener su propia stanza en el fichero Fileset.fixdata. Una estrofa Fileset.fixdata tiene el siguiente formato:

fix:
name = FixKeyword
abstract = Abstract
type = {f | p}
filesets = FilesetName FilesetLevel
[FilesetName FilesetLevel ...]
[symptom = [Symptom]]

El siguiente ejemplo muestra una stanzaFileset.fixdata para un problemaMS21235. La solución a este problema se encuentra en dos conjuntos de archivos.

fix:
name = MS21235
abstract = 82 gigabyte diskette drive unusable on Mars
type = f
filesets = devices.mca.8d77.rte 12.3.6.13
devices.mca.8efc.rte 12.1.0.2
symptom = The 82 gigabyte subatomic diskettes fail to operate in a Martian environment.

El archivo Fileset.inventory

El archivo Fileset.inventory es necesario para cada parte de un fileset que instale o actualice archivos. Si el paquete tiene una parte raíz que no contiene archivos a instalar (sólo hace configuración), la parte raíz no requiere el archivo Fileset.inventory.

Nota: El archivo Fileset.inventory no admite archivos de más de 2 GB de tamaño. Si envía un archivo de más de 2 GB, inclúyalo en su archivo fileset.al, pero no en su archivo Fileset.inventory. sysck no ha sido actualizado para manejar archivos mayores de 2GB, y el sistema de archivos /usr en la mayoría de las máquinas no será creado con capacidad para archivos mayores de 2GB (por defecto).

El archivo de inventario consta de texto ASCII en formato de stanza. El nombre de una stanza es el nombre completo de la vía de acceso del archivo que se va a instalar. El nombre de stanza termina con dos puntos (:) y va seguido de un carácter de nueva línea. Los atributos del fichero siguen al nombre de la estrofa y tienen el formato Atributo=Value. Cada atributo se describe en una línea separada.

inventory:
type     = type
class    = inventory,apply,C2_exclude,fileset
owner    = owner_name
group    = group_name
mode     = TCB | SUID | SGID,permissions
target   = fullpath_filename
link     = fullpath_to_hardlink [additional_hardlinks]
size     =<blank> | VOLATILE |size
checksum =<blank> | VOLATILE |"checksum"

fileset.inventory ejemplo

El siguiente ejemplo de fileset.inventory demuestra el uso de ' type.

/usr/bin:
        owner = bin
        group = bin
        mode = 755
        type = directory
        class = apply,inventory,bos.rte


/usr/bin/tcbck:
        owner = root
        group = security
        mode = TCB,SUID,550
        type = file
        class = apply,inventory,bos.rte.security
        size = 99770
        checksum = "17077     98 "


/usr/sbin/tsm:
        owner = root
        group = security
        mode = TCB,SUID,555
        links = /usr/sbin/getty,/usr/sbin/login
        class = apply,inventory,bos.rte,security
        size = 55086
        checksum = "57960     54 "

Ficheros de control de la instalación específicos para productos reenvasados

Fileset.installed_list

Fichero creado por el comando installp al instalar el fileset desde un paquete si se detecta que el fileset (o alguna forma del mismo) ya está instalado en el sistema a algún nivel

Se busca en la base de datos de información de software para determinar si Fileset o cualquiera de los filesets listados en el archivo Fileset.namelist (si existe) ya están instalados en el sistema. En caso afirmativo, el conjunto de archivos y el nivel de instalación se escriben en el archivo Fileset.installed_list.

El archivo Fileset.installed_list contiene una entrada de una línea por cada fileset que se instaló. Cada entrada contiene el nombre del conjunto de archivos y el nivel del conjunto de archivos.

storm.rain 1.1.0.0

Pelly.com
GooseCreek.rte
CedarBayou.stream 

Pelly.obj 1.2.3.0
CedarBayou.stream 4.1.3.2

El archivo Fileset.namelist debe proporcionarse en la parte ' usr o ' root ' del archivoliblppliblpp.a. El Fileset.namelist sólo es válido para paquetes de instalación; no es válido para paquetes de actualización.

Al comienzo de la instalación, el comando installp busca en el Software Vital Product Data (SWVPD) para determinar si el fileset o cualquier fileset listado en el archivo Fileset.namelist ya está instalado en el sistema. El comando installp escribe en el archivo Fileset.installed_list los nombres de los conjuntos de archivos y los niveles de los conjuntos de archivos que se encuentran instalados, poniendo esta información a disposición de los ejecutables proporcionados por el producto.

family.business

lawoffice.mgr

lawoffice.mgr
BusinessOffice.mgr

Si el archivo Fileset.namelist sólo contiene una entrada y el juego de archivos actual no es un sustituto directo del juego de archivos que aparece en la lista Fileset.namelist, debe incluir un archivo Fileset.rm_inv en el archivo liblpp.a. El proceso de instalación utiliza el archivo Fileset.namelist y el archivo Fileset.rm_inv para determinar si un fileset es un reemplazo directo de otro fileset. Si el archivo Fileset.namelist contiene sólo una entrada y no hay ningún archivo Fileset.rm_inv, el proceso de instalación asume que el nuevo fileset es un reemplazo directo del antiguo fileset. Cuando se instala el nuevo conjunto de archivos (sustituto), el proceso de instalación elimina del sistema todos los archivos del antiguo conjunto de archivos (sustituido), incluso los archivos no incluidos en el nuevo conjunto de archivos.

En los ejemplos anteriores, elsmall.businesses un sustituto directo defamily.businesspor lo quesmall.business.rm_invno debe existir. Los 2LawPractice.clientno sustituye directamente alawoffice.mgrpor lo queLawPractice.client.rm_invdebe existir, aunque esté vacío.

Ejemplo 3:

bread.shop.rte
bagel.shop.rte

También debe enviar un archivo ' bread.shop.rte.rm_inv ' vacío para indicar que todos los archivos del conjunto de archivos ' bagel.shop.rte ' deben eliminarse del sistema.

Este archivo se utiliza cuando el conjunto de archivos actual se empaqueta de forma diferente a un nivel anterior del conjunto de archivos y el proceso de instalación no debe eliminar los archivos instalados previamente basándose en las entradas del conjunto de archivos en la base de datos de inventario.

Un simple cambio de nombre de un fileset no es suficiente para requerir un fichero Fileset.rm_inv. El archivo Fileset.rm_inv es necesario cuando un nuevo fileset es un subconjunto de un fileset anterior o una mezcla de partes de filesets anteriores. Si existe un archivo Fileset.namelist y contiene entradas para más de un fileset, debe utilizar el archivo Fileset.rm_inv para eliminar del sistema los niveles de los archivos instalados previamente.

El archivo Fileset.rm_inv consta de texto ASCII en formato de estrofa. El nombre de una stanza es el nombre completo de la vía de acceso del archivo o directorio que se va a eliminar si se encuentra en el sistema. El nombre de la estrofa termina con dos puntos (:) y va seguido de un carácter de nueva línea. Si los atributos siguen al nombre de la estrofa, los atributos tienen el formato Atributo=Valor. Los atributos se utilizan para identificar enlaces fijos y enlaces simbólicos que deben eliminarse. Cada atributo se describe en una línea separada. La siguiente lista describe los atributos válidos asociados al archivo de la lista:

Por ejemplo, supongamos queU.S.S.R 19.91.0.0contiene los siguientes archivos en el directorio /usr/lib:moscow,leningrad,kiev,odessa, ypetrograd(un enlace simbólico aleningrad). Los desarrolladores del producto deciden dividir elU.S.S.R 19.91.0.0en dos conjuntos de archivos:Ukraine.lib 19.94.0.0yRussia.lib 19.94.0.0. EnUkraine.libcontiene los archivoskievyodessa. Los 2Russia.libcontiene los archivosmoscow.xlsx Los 2leningradya no existe y se sustituye por el archivost.petersburgen el archivoRussia.libfileset.

Los 2Ukraine.lib.rm_invdebe existir porque el archivoUkraine.libno sustituye directamente aU.S.S.Rfileset. Los 2Ukraine.lib.rm_invdebe estar vacío, ya que no es necesario eliminar ningún archivo cuando se ejecuta la aplicaciónUkraine.libse instala para limpiar la migraciónU.S.S.Rfileset.

/usr/lib/leningrad:
 symlinks = /usr/lib/petrograd
/usr/lib/petrograd:

Archivos de instalación para subsistemas de disco suplementarios

Un subsistema de disco que no se configurará con el controlador de dispositivo conectado a bus o SCSI proporcionado requiere su propio controlador de dispositivo y métodos de configuración. Estos archivos de instalación se proporcionan en un disquete suplementario (que acompaña al dispositivo) y deben estar en formato de copia de seguridad con un archivo ./signature y un archivo ./startup. El archivo de firma debe contener la cadena objetivo. El archivo de inicio debe utilizar la restauración por nombre para extraer los archivos necesarios del disquete suplementario y para ejecutar los mandatos necesarios para llevar el dispositivo al estado disponible.

Formato de los medios de distribución

Los siguientes tipos de soportes se pueden utilizar para distribuir paquetes de instalación de productos de software.

En las secciones siguientes se describen los formatos que se deben utilizar para distribuir varios paquetes de producto en cada uno de estos soportes.

Cinta

Para apilar varias imágenes de paquete de producto en una sola cinta o en un conjunto de cintas, los archivos de cada cinta del conjunto deben ajustarse al formato siguiente:

• El archivo 1 está vacío. (Reservado para cintas arrancables.)
• El archivo 2 está vacío. (Reservado para cintas arrancables.)
• El archivo 3 contiene un archivo de tabla de contenido que describe imágenes de paquete de producto en el conjunto de cintas. Por lo tanto, cada cinta del conjunto contiene una copia del mismo archivo de tabla de contenido, excepto por la diferencia del número de volumen de cinta en un conjunto de varios volúmenes.
• Los archivos 4 a(N+3) contienen las imágenes de archivo en formato de copia de seguridad de los paquetes de productos1a través de N.
• Un archivo de imagen de paquete de producto no puede abarcar dos cintas.
• Cada archivo va seguido de una marca de cinta de fin de archivo.

CD-ROM

Un CD-ROM que debe contener varias imágenes de paquete de producto debe cumplir con el protocolo Rock Ridge Group Protocol. Los paquetes de productos deben almacenarse en el directorio de instalación, que debe contener lo siguiente:

• Las imágenes de archivo de formato de copia de seguridad de los paquetes del producto.
• Un archivo de índice denominado .toc que describe las imágenes de los paquetes de productos del directorio.

Un CD-ROM de varios volúmenes es un CD-ROM que tiene una estructura de directorios adicional para definir un conjunto de CD-ROM como una sola unidad instalable.

AIX 5.2 Ejemplo:

el conjunto de archivos A está en el archivo A.bff del volumen 1. el conjunto de archivos B está en el archivo B.bff del volumen 2. El campo del archivo de índice en /installp/mvCD que contiene la ubicación de las imágenes del paquete del producto para A y B son vol%1/A.bff y vol%2/B.bff, respectivamente. El campo del archivo de índice en /installp/ppc del volumen 1 contiene la ubicación de A como A.bff. El campo del archivo de índice en /installp/ppc del volumen 2 contiene la ubicación de B como B.bff.

La estructura de directorios de CD-ROM para AIX 5.1 y posteriores permite especificar otros instaladores, así como varias plataformas.

Disquete

Para apilar varias imágenes de paquete de producto en un conjunto de disquetes, se deben escribir los archivos siguientes en el conjunto de disquetes:

• Archivo de tabla de contenido que describe las imágenes de paquete de producto que se van a incluir en el conjunto.
• Cada archivo de imagen de paquete de producto que se va a incluir en el conjunto.

Los archivos se escriben en el conjunto de disquetes siguiendo las siguientes reglas:

• Grabe los datos como una corriente en el conjunto de disquetes con un sector de ID de volumen insertado en el bloque 0 de cada disquete del conjunto. Los datos del último bloque de un volumen se tratan como lógicamente adyacentes a los datos del bloque 1 del siguiente volumen (el sector de ID de volumen se verifica y se descarta cuando se lee).
• Cada archivo empieza en un límite de bloque de 512 bytes.
• Escriba primero el archivo de tabla de contenido. Rellenar este archivo para llenar su último sector con caracteres nulos (x'00'). Se requiere al menos un carácter nulo para marcar el final del archivo de índice. Por lo tanto, puede ser necesario un sector completo de caracteres nulos.
• Siguiendo el archivo de tabla de contenido, escriba cada uno de los archivos de imagen de paquete de producto en sectores sucesivos. Rellena cada fichero hasta su último sector con caracteres nulos. No es necesario un carácter nulo si el archivo finaliza en el límite de bloque.
• El bloque 0 de cada disquete del conjunto contiene un sector de ID de volumen. El formato de este sector es:

  Posición	Descripción
  Bytes 0: 3	Un número mágico para la identificación. Se trata de un número entero binario con valor decimal3609823513=x'D7298918'.
  Bytes 4:15	Un sello de fecha y hora (en ASCII) que sirve de identificación para el conjunto de disquetes. El formato es MonthDayHourMinuteSecondYear. La Hora debe ser un valor de 00 a 23. Todos los campos de fecha y hora contienen dos dígitos. Por lo tanto, Mes debe representarse como03En lugar de3y Año debe representarse como94En lugar de1994.
  Bytes 16:19	Un número de volumen entero binario dentro de este conjunto de disquetes. El primer disquete del juego esx'00000001'.
  Bytes 20:511	Ceros binarios.

Formato de fecha y hora

Un formato de sello de fecha y hora es una cadena ASCII que tiene el siguiente formato:

MonthDayHourMinuteSecondYear

La Hora debe ser un valor de 00 a 23. Todos los campos de fecha y hora contienen dos dígitos. Por lo tanto, Mes debe representarse como03En lugar de3y Año debe representarse como94En lugar de1994.

Formato de ubicación para cinta y disquete

La ubicación tiene el formato vvv:bbbbb:sssssss donde cada letra representa un dígito y tiene el significado siguiente:

Para cinta

vvv

es el número de volumen de la cinta.

bbbb

es el número de archivo en la cinta de la imagen del paquete del producto.

SSSSSSSS

es el tamaño del archivo en bytes.

Para disquete

vvv

es el número de volumen del disquete.

bbbb

es el número de bloque del disquete donde comienza el archivo de imagen del paquete de productos.

SSSSSSSS

es el tamaño del archivo en bytes (incluido el relleno hasta el final del límite del bloque).

Instalación reubicableAIX

Mientras que la instalación reubicable AIX está ahora soportada con las utilidades de instalación nativas AIX (como installp, instfix, lslpp, y lppchk), el uso de la reubicación es de particular interés para aplicaciones que necesitan ser instaladas dentro de una Partición de Carga de Trabajo. Esto se debe a que las configuraciones WPAR del sistema por defecto no incluyen un sistema de archivos /usr o /opt en el que se pueda escribir. Por lo tanto, puede que sea necesario reorientar la instalación de aplicaciones a ubicaciones distintas de las tradicionales /usr o /opt.

Terminología

vía de acceso de instalación raíz

El directorio base donde está instalada una aplicación. La ruta de instalación por defecto de installp es"/".

vía de acceso de instalación predeterminada

La ruta de instalación raíz por defecto (es decir,"/").

vía de acceso de instalación reubicada

Cualquier ruta de instalación raíz que no sea la ruta de instalación por defecto. La ubicación de la ruta puede ser cualquier ruta válida que no sea"/" y que tenga un tamaño no superior a 512 caracteres.

aplicación reubicable

Una aplicación que puede instalarse en una ruta de instalación raíz no predeterminada.

USIL (Ubicación de instalación especificada por el usuario)

Una instancia de vía de acceso de instalación reubicada configurada por el usuario.

USIL

Una ubicación de instalación especificada por el usuario, o USIL, es una vía de acceso de instalación reubicada de seguimiento creada por el administrador. El sistema realiza un seguimiento de esta ubicación y puede utilizarse como ruta de instalación alternativa para los paquetes que admiten la reubicación. Se pueden instalar múltiples instancias y/o versiones del mismo paquete de software en un solo sistema delegando cada instalación a una USIL separada. Una instancia de USIL existente puede estar conectada o desconectada de cualquier sistema determinado.

Mandatos de gestión de USIL

/usr/sbin/mkusil

Crea o conecta una nueva instancia de USIL.

mkusil -R RelocatePath -c Comentarios[XFa]

-a

Conecta una instalación existente como una instancia de USIL

-c

Comentarios que se deben incluir en la definición de USIL (visibles con el mandato lsusil)

-R

Ruta de acceso a la nueva ubicación de USIL. Debe ser un directorio válido.

-X

Expandir automáticamente el espacio necesario

/usr/sbin/lsusil

Lista las instancias de USIL existentes.

lsusil[-R RelocatePath | "TODOS"]

-R

Ruta a la ubicación USIL existente.

/usr/sbin/rmusil

Elimina una instancia de USIL existente.

rmusil -R RelocatePath

-R

Ruta a la ubicación USIL existente.

/usr/sbin/chusil

Cambia un atributo de una instancia de USIL existente.

chusil -R RelocatePath -c NewComments[X]

-c

Nuevos comentarios para incluir en la definición de USIL (visible con el comando lsusil ).

-R

Ruta a la ubicación USIL existente.

-X

Expansión automática si se necesita espacio

Programas de utilidad de instalación reubicable

Requisitos para el embalaje de aplicaciones reubicables

Requisitos para la ejecución de aplicaciones reubicables

Objeto de clase ODM de conector de USIL

El objeto de clase ODM del conector USIL reside en el archivo /etc/objrepos/usilc y contiene datos que vinculan el SWVPD predeterminado con todas las instancias USIL.

/*  User Install Location Connector                                    */
/*  Connects the default install path to all relocated install paths.  */
class   usilc {
        vchar   path[1024];             /* USIL path */
        vchar   comments[2048];   /* USIL Comments */
        long    flags;                       /* USIL flags */
        };     

Listado de todas las rutas de instalación con la opción -R "ALL" o -R "all"

Los comandos lslpp y lppchk pueden realizar operaciones de listado en todas las ubicaciones de instalación si se utiliza la sintaxis -R "ALL".

Operaciones de conexión/desconexión

La operación de conexión permite al usuario integrar una ruta USIL independiente existente en el SWVPD.

Por ejemplo, si el administrador crea una instancia USIL maestra con varias aplicaciones reubicables instaladas con el propósito de alojar aplicaciones. Después, el administrador copia o monta en NFS esta instancia de USIL en varios sistemas y utiliza la característica de conexión para integrar la instancia de USIL en SWVPD. La operación de desconexión elimina la referencia a la instancia de USIL.

Licencia de installp

Una nueva instancia de USIL se inicia con un LAG (clase de objeto ODM de contrato de licencia de installp) vacío. Cualquier instalación de conjuntos de archivos o LPP que requiera una licencia requerirá una aceptación de licencia de acuerdo con las convenciones normales de installp. La aceptación de la licencia no distribuye instancias de USIL.

|Base informática de confianza (TCB)

La instalación de instancias de USIL no está soportada actualmente en sistemas habilitados para TCB.

Requisitos reubicables

Una nueva semántica de empaquetado indica la ubicación de requisito reubicable. Un empaquetador puede especificar que un requisito determinado se debe buscar en el vía de acceso de instalación por omisión o en la vía de acceso de instalación reubicada.

Los tipos de requisitos definidos actualmente (prereq, ifreq, coreq e instreq) son todos requisitos por omisión (requisitos que se aplican a la ubicación de instalación por omisión).

Cambios de TOC para paquetes reubicables

sscp.rte.1.0.0.5.U.PRIVATE.bff 4 R S sscp {
sscp.rte 01.00.0000.0005 1 N B En_US Sscp
[
*coreq bos.games 1.1.1.1  <-- default requisite in default requisite section
*prereq bos.rte 1.1.1.1   <-- default requisite in default requisite section
%
/usr/bin 20
/etc 20
INSTWORK 72 40
%
%
%
IY99999  1 APAR text here.
%
RELOCATABLE <-- attribute tag to denote relocatable package
%
*prereq bos.rte 1.1.1.1 <-- default requisite in relocated requisite section
*coreq_r bos.games 1.1.1.1 <-- relocated requisite in relocated requisite section
]
}

Los ejecutables proporcionados dentro de un paquete de productos pueden adaptar el procesamiento para las operaciones de aplicar, rechazar y eliminar.

La reinstalación de un conjunto de archivos no realiza las mismas acciones que la eliminación e instalación del mismo conjunto de archivos. La acción de reinstalación (véase /usr/lib/instl/rminstal) limpia los archivos actuales de la versión anterior o de la misma versión, pero no ejecuta ninguno de los scripts unconfig o unpre*. Por lo tanto, no asuma que se ha ejecutado el script unconfig. El script .config debería comprobar el entorno antes de asumir que la desconfiguración se ha completado.

Por ejemplo, para un conjunto de archivos ras.berry.rte, el script config añade una línea al archivo crontab de root. Al reinstalar el conjunto de archivos ' ras.berry.rte ' aparecen dos entradas crontab ', porque el script ' desconfigurar ' no se ejecutó al reinstalar (lo que eliminó la entrada ' crontab '). El script de configuración siempre debe eliminar la entrada y luego añadirla de nuevo.

Tratamiento de la operación de aplicación

Esta sección describe los pasos que sigue el comando installp cuando se aplica una actualización de fileset o fileset.

1. Restaura el archivo de información del paquete de productos lpp_name para el paquete del dispositivo especificado.
2. Verifique que los conjuntos de archivos solicitados existen en el soporte de instalación.
3. Compruebe el nivel de los conjuntos de archivos solicitados para asegurarse de que pueden estar instalados en el sistema.
4. Restaurar los archivos de control del archivo de biblioteca liblpp.a en el directorio del paquete(/usr/lpp/Nombre_del_paquete para paquetes usr o usr/root. Los archivos de control específicos para la parte ' raíz ' de un paquete ' usr/root ' residen en ' /usr/lpp/ 'Nombre_paquete '/inst_root/liblpp.a).
5. Compruebe los requisitos de espacio de disco.
6. Compruebe que los requisitos necesarios (conjuntos de archivos que deben estar en determinados niveles para utilizar o instalar otro conjunto de archivos) ya están instalados o están en la lista para ser instalados.
7. Determine si existen requisitos del acuerdo de licencia que deban cumplirse para proceder a la instalación.
8. Si se trata de un paquete de instalación en lugar de un paquete de actualización de fileset, busque en los datos vitales del producto de software (SWVPD) para ver si Fileset (el fileset que se está instalando) o cualquier fileset enumerado en el archivo Fileset.namelist ya están instalados en el sistema a cualquier nivel. Si Fileset ya está instalado, escriba el nombre del fileset y el nivel instalado en el archivo Work_Directory/Fileset.installed_list.

   Si no hay ningún nivel de Fileset instalado, entonces si hay algún fileset listado en el fichero Fileset.namelist instalado, lista todos esos filesets y niveles en el ficheroWork_Directory/Fileset.installed_list. ' Directorio_de_trabajo es el mismo que el directorio del paquete a excepción de las partes ' raíz ', que utilizan/lpp/' 'Nombre_paquete.

9. Si se trata de un paquete de instalación en lugar de un paquete de actualización de conjuntos de archivos, ejecute el script /usr/lib/instl/rminstal para hacer lo siguiente para cada conjunto de archivos que se va a instalar.
   Nota: A menos que se especifique lo contrario, los archivos cuya existencia se comprueba deben haber sido restaurados desde la biblioteca de archivos de control liblpp.a.
   1. Si Fileset.pre_rm existe, ejecute Fileset.pre_rm para realizar los pasos necesarios antes de eliminar cualquier archivo de esta versión o de una versión existente de Fileset.
   2. Si ' Directorio_de_trabajo/ 'Conjunto de archivos '.lista_instalada existe, mueva los archivos existentes listados en ' Conjunto de archivos.cfgfiles al directorio de guardado de archivos de configuración (indicado por la variable de entorno ' MIGSAVE ).
   3. Si ya está instalada una versión de Conjunto de archivos , elimine los archivos y la información de SWVPD (excepto el historial) para Conjunto de archivos.
   4. Si ' Directorio_de_trabajo/ 'Conjunto de archivos '.lista_instalada existe, y ' Conjunto de archivos '.rm_inv existe o ' Fileset. 'namelist contiene más de un fileset o el único fileset listado en ' Conjunto de archivos '.namelist esbos.objhaga lo siguiente:
      1. Elimina los archivos y la información de inventario de SWVPD de los archivos enumerados en el archivo Fileset.rm_inv.
      2. Elimina los archivos y la información de inventario SWVPD de los archivos enumerados en el archivo Fileset.inventory.
      3. Elimine otra información de SWVPD para los conjuntos de archivos enumerados en Fileset.namelist que ya no tengan información de inventario de SWVPD.
   5. Si ' Directorio_de_trabajo/ 'Conjunto de archivos. 'lista_instalada existe y sólo contiene un conjunto de archivos y ' Conjunto de archivos' '.namelist sólo contenía un conjunto de archivos, elimine los archivos y la información SWVPD (excepto el historial) de ese conjunto de archivos.
   6. Para cada parte de un envase de producto (sólo la parteusr " o " usr seguida de " raíz)
      1. Establezca las variables de entorno INUTREE(U para usr y M para root) e INUTEMPDIR (nombre del directorio de trabajo temporal creado.
      2. Si existe un programa de control de instalación en el directorio del paquete (no recomendado), ejecute ./instal, de lo contrario, ejecute el script por defecto /usr/lib/instl/instal. Si no existe un programa de control de instalaciones en el directorio del paquete, configure la variable de entorno INUSAVEDIR.
      3. Si existe un programa de control de actualizaciones en el directorio del paquete (no recomendado), ejecute ./update. Si no existe un programa de control de actualizaciones en el directorio del paquete, ejecute el script por defecto /usr/lib/instl/update.
      4. Si se ha creado correctamente un archivo de estado mediante instalación o actualización, utilice el archivo de estado para determinar el éxito o el fracaso de cada conjunto de archivos. Si no se ha creado un archivo de estado, se asume que no se han aplicado todos los conjuntos de archivos solicitados en el paquete.
      5. Si la operación de aplicación de un conjunto de archivos se ha realizado correctamente, actualice los Datos Vitales del Producto de Software (SWVPD) y, a continuación, registre cualquier requisito de acuerdo de licencia asociado. Si la operación de aplicación de un conjunto de archivos no se ha realizado correctamente, ejecute /usr/lib/instl/cleanup o el lpp.cleanup proporcionado por el paquete desde el directorio del paquete para limpiar los conjuntos de archivos que han fallado.

Procesamiento del script de instalación o actualización por defecto

El ejecutable de instalación o actualización se invoca desde installp, siendo el primer parámetro el dispositivo utilizado para la instalación o actualización. El segundo parámetro es el nombre completo de la ruta al archivo que contiene la lista de conjuntos de archivos que deben instalarse o actualizarse, denominado a continuación $FILESETLIST. Los scripts instal y update por defecto están vinculados entre sí; el procesamiento varía en función de si se invoca como instal o update.El directorio actual es el directorio del paquete. Se crea un directorio temporal INUTEMPDIR en /tmp para guardar los archivos de trabajo.

El flujo dentro del script de instalación y actualización por defecto es el siguiente:

1. Haga lo siguiente para cada conjunto de archivos de la lista $FILESETLIST:
   1. Si el conjunto de archivos es una actualización, ejecute Fileset.pre_u (pre_update) si existe. Si el conjunto de archivos no es una actualización, ejecute Fileset.pre_i (pre_instalación) si existe.
   2. Construir una lista maestra de archivos a restaurar del paquete anexando Fileset.al al nuevo archivo INUTEMPDIR/master.al.
   3. Si se trata de una actualización, se especifica que se guarden los archivos y existe el archivo de control lpp.acf.

      Salve los miembros de archivado de biblioteca que se están actualizando.

   4. Si el proceso se realiza correctamente, añada este conjunto de archivos a la lista que debe instalarse en el archivo $FILESETLISTFILESETLIST.new.
2. Si se trata de una actualización y se especifica guardar archivos, ejecute inusave para guardar las versiones actuales de los archivos.
3. Si está procesando la parte raíz, ejecute inucp para copiar los archivos de la lista de aplicaciones a la parte raíz. Si no está procesando la parte raíz, ejecute inurest para restaurar los archivos de la lista apply para la parte ' usr '.
4. Haga lo siguiente para cada fileset listado en el archivo $FILESETLISTFILESETLIST.new:
   Nota: El fallo en cualquier paso se registra en el archivo de estado y finaliza el procesamiento de ese conjunto de archivos
   1. Determina si este fileset está instalado en el mismo nivel o en un nivel anterior, o si los filesets listados en Fileset.namelist están instalados. Si es así, exporte las variables de entorno INSTALLED_LIST y MIGSAVE. Esto se denomina migración.
   2. Si está procesando una actualización, invoque Fileset.post_u si existe. Si ' Conjunto de archivos '.post_u no existe, invoca ' Conjunto de archivos '.post_i si existe.
   3. Si Fileset.cfgfiles existe, ejecute /usr/lib/instl/migrate_cfg para manejar el procesamiento de los archivos de configuración de acuerdo a su método de manejo especificado.
   4. Invoca sysck para añadir la información del archivo Fileset.inventory a la Base de Datos de Productos Vitales de Software (SWVPD).
   5. Invoca el comando tcbck para añadir la información de la base de cálculo de confianza al sistema si el archivo Fileset.tcb existe y el atributo tcb_enabled de la base de cálculo de confianza está establecido en la base de datos /usr/lib/objrepos/PdAt ODM.
   6. Invoca errupdate para añadir plantillas de error si Fileset.err existe.
   7. Invoca trcupdate para añadir plantillas de formato de informe de rastreo si Fileset.trc existe.
   8. Si se actualiza o si ' Directorio_de_trabajo/ 'Conjunto de archivos '.lista_instalada existe, invoque cada script ' Conjunto de archivos '.odmdel y ' Conjunto de archivos '.*.odmdel para procesar los comandos de eliminación de la base de datos ' ODM.
   9. Invoque odmadd en cada Fileset.odmadd y Fileset.*.odmadd existente para añadir información a las bases de datos ODM.
   10. Si se trata de una actualización, invoca Fileset.config_u (actualización de la configuración del fileset) si existe. En caso contrario, invoca Fileset.config (configuración del fileset) si existe.
   11. Actualiza el archivo de estado indicando que el conjunto de archivos se ha procesado correctamente.
5. Vincula los archivos de control necesarios para la eliminación del conjunto de archivos en el directorio deinstl del paquete para su uso futuro. Estos archivos incluyen los archivos siguientes que pueden estar presentes en el directorio del paquete:
   • lpp.deinstal
   • Fileset. al
   • Fileset. Inventario
   • Fileset. pre_d
   • Fileset. unpre_i
   • Fileset. unpre_u
   • Fileset. unpost_i
   • Fileset. unpost_u
   • Fileset. unodmadd
   • Fileset. unconfig
   • Fileset. desconfig_u
   • $SAVEDIR/Fileset. *.rodmadd
   • SAVEDIR/Fileset. *.unodmadd

Tratamiento de las operaciones de rechazo y limpieza

En esta sección se describen los pasos que sigue el comando installp cuando se rechaza una actualización de un fileset o cuando un fileset o una actualización de un fileset no consiguen completar la instalación. Los scripts predeterminados de limpieza y rechazo ubicados en /usr/lib/instl están vinculados entre sí. Su lógica difiere ligeramente dependiendo de si el script fue invocado como rechazo o limpieza. Para los conjuntos de archivos " usr" /raíz " o las actualizaciones de conjuntos de archivos, la parte " raíz " se procesa antes que la parte " usr ".

1. Si se rechaza, compruebe los requisitos para asegurarse de que también se rechazan todas las actualizaciones de producto dependientes.
2. Para cada parte de un paquete (por ejemplo, usr y root):
   1. Establecer INUTREE(U para usr y M para root.) e INUTEMPDIR.
   2. Si el archivo de control reject existe en el directorio actual(INULIBDIR), invoque ./lpp.reject. En caso contrario, invoca el script por defecto /usr/lib/instl/reject.
3. Actualice los datos vitales del producto de software.

El ejecutable reject es invocado desde installp con el primer parámetro siendo undefined y el segundo parámetro siendo el nombre completo de la ruta al archivo que contiene la lista de filesets (referido más abajo como $FILESETLIST) a ser rechazados para la actualización.

El script de limpieza y rechazo por defecto hace referencia a los siguientes archivos.

El flujo dentro del script de limpieza y rechazo por defecto es el siguiente:

1. Haga lo siguiente para cada conjunto de archivos enumerado en $FILESETLIST:
   1. Si se invoca como limpieza, entonces lee la línea en el archivo de estado de Package_Name.s para determinar en qué paso falló la instalación y salta a la acción de deshacer para ese paso. Una operación de limpieza sólo comenzará en el paso en el que falló la instalación. Por ejemplo, si la instalación de un conjunto de archivos fallara en el script Fileset.post_i, entonces la operación de limpieza para ese conjunto de archivos comenzaría en i, porque no hay acciones que deshacer de los pasos posteriores de la instalación.
   2. Deshaga cualquier proceso de configuración realizado durante la instalación:

      Si rechaza una actualización, invoque Fileset.unconfig_u si existe. En caso contrario, invoca Fileset.unconfig si existe.

   3. Ejecute los archivos Fileset.*.unodmadd y/o Fileset.unodmadd para eliminar las entradas de Object Data ManagerODM) añadidas durante la instalación.
   4. Ejecute cualquier Fileset.*.rodmadd y/o Fileset.rodmadd existente para reemplazar las entradas ODM eliminadas durante la instalación.
   5. Invocaretrcupdate si Fileset.undo.trc existe para deshacer cualquier cambio de plantilla de formato de traza realizado durante la instalación.
   6. Invoca errupdate si Fileset.undo.err existe para deshacer cualquier cambio de plantilla de formato de error realizado durante la instalación.
   7. Invoca tcbck para eliminar la información de la base de cálculo de confianza al sistema si el archivo Fileset.tcb existe y el atributo de base de cálculo de confianza tcb_enabled está establecido en la base de datos /usr/lib/objrepos/PdAt ODM.
   8. Invoca sysck si Fileset.inventory existe para deshacer los cambios en la base de datos de información de software.
   9. Deshacer cualquier proceso post_instalación realizado durante la instalación:

      Si se trata de una actualización, invoque Fileset.unpost_u si existe. En caso contrario, invoca Fileset.unpost_i si existe.

   10. Construye una lista maestra de aplicaciones (llamada master.al) a partir de los archivos Fileset.al.
   11. Añadir Fileset a $FILESETLISTFILESETLIST.new.
2. Haga lo siguiente si $INUTEMPDIR/masterINUTEMPDIR/master.al existe.
   1. Cambia los directorios a /(root).
   2. Elimina todos los archivos de master.al.
3. Haga lo siguiente mientras lee $FILESETLISTFILESETLIST.new.
   1. Llama a inurecv para recuperar todos los archivos guardados.
   2. Si se trata de una actualización, invoque Fileset.unpre_u si existe. En caso contrario, invoca Fileset.unpre_i si existe.
   3. Suprima los archivos de control de instalación/actualización.
4. Elimina el archivo de estado Package_Name.s.

Tratamiento de la operación de eliminación

Esta sección describe los pasos que sigue el comando installp cuando se elimina un fileset. Para los conjuntos de archivos " usr" /raíz " o las actualizaciones de conjuntos de archivos, la parte " raíz " se procesa antes que la parte " usr ".

1. Compruebe los requisitos para asegurarse de que todos los conjuntos de archivos dependientes también se han eliminado.
2. Para cada parte de un paquete de productos (por ejemplo, usr o root):
   1. Establezca las variables de entorno INUTREE (U para ' usr, M para ' raíz, y S para ' compartir' ) e INUTEMPDIR ( directorio de trabajoinstale generado en /tmp).
   2. Cambia el directorio a INULIBDIR.
   3. Si el archivo de control ' desinstalar ' existe en el directorio actual, ejecute el script ' ./lpp.deinstal. Si el archivo de control de desinstalación no existe en el directorio actual, ejecute el script por defecto /usr/lib/instl/deinstal.
3. Elimine los archivos que pertenecen al conjunto de archivos del sistema de archivos.
4. Elimine las entradas de conjunto de archivos de SWVPD excepto para los datos de historial.
5. Desactivar el registro de requisitos del acuerdo de licencia para el conjunto de archivos.

El ejecutable deinstal se invoca desde installp con el primer parámetro siendo el nombre completo de la ruta al fichero que contiene la lista de conjuntos de ficheros a eliminar, referido más adelante como $FILESETLIST.

El flujo dentro del script de desinstalación por defecto es el siguiente:

1. Haga lo siguiente para cada conjunto de archivos enumerado en el archivo de entrada $FILESETLIST:
2. Si Fileset.unconfig_d existe

   Ejecute Fileset.unconfig_d para eliminar todos los cambios de configuración, los cambios de Object Data ManagerODM) y los cambios de formato de error y rastreo, y para deshacer todas las operaciones realizadas en los scripts de postinstalación y preinstalación para todas las actualizaciones y la instalación de nivel básico. No se recomienda utilizar este archivo.

3. Si Fileset.unconfig_d no existe,
   1. Para cada actualización de ese conjunto de archivos, haga lo siguiente:
      • Ejecute todos los scripts Fileset.unconfig_u para deshacer cualquier proceso de configuración de actualizaciones.
      • Ejecute todos los Fileset.*.unodmadd y Fileset.unodmadd para eliminar las entradas de Object Data ManagerODM) añadidas durante la actualización.
      • Ejecute todos los Fileset.*.rodmadd y Fileset.rodmadd para añadir las entradas de Object Data ManagerODM) eliminadas durante la actualización.
      • Ejecute errupdate si Fileset.undo.err existe para deshacer los cambios en la plantilla del registro de errores.
      • Ejecute trcupdate si Fileset.undo.trc existe para deshacer los cambios en la plantilla del informe de seguimiento.
      • Ejecute cualquier Fileset.unpost_u para deshacer cualquier personalización posterior a la instalación.
   2. Para el nivel de instalación base de conjunto de archivos, haga lo siguiente:
      • Ejecute cualquier Fileset.*.unodmaddy/o Fileset.unodmadd para eliminar las entradas de Object Data ManagerODM) añadidas durante la instalación.
      • Ejecute cualquier Fileset.*.rodmadd y/o Fileset.rodmadd para añadir las entradas de Object Data ManagerODM) eliminadas durante la instalación.
      • Ejecute errupdate si Fileset.undo.err existe para deshacer los cambios en la plantilla del registro de errores.
      • Ejecute trcupdate si Fileset.undo.trc existe para deshacer los cambios en la plantilla del informe de seguimiento.
      • Ejecute Fileset.unconfig_i para deshacer cualquier proceso de configuración de la instalación.
      • Ejecute Fileset.unpost_i para deshacer cualquier personalización posterior a la instalación del archivo.
4. Elimina los archivos y la información de datos de software instalados con el conjunto de archivos.
5. Si Fileset.unconfig_d no existe,
   1. Para cada actualización de ese fileset, ejecute cualquier Fileset.unpre_u para deshacer cualquier personalización previa a la instalación del fileset.
   2. Para el nivel de instalación base del fileset, ejecute cualquier Fileset.unpre_i para deshacer cualquier personalización previa a la instalación del fileset.
6. Suprima los directorios vacíos asociados con el conjunto de archivos.
   Nota: Si se devuelve un error de alguna llamada durante la ejecución del ejecutable deinstal, se registrará el error, pero la ejecución continuará. Esto es diferente de los otros scripts porque la ejecución para ese conjunto de archivos normalmente se cancela una vez que se encuentra un error. Sin embargo, una vez que la eliminación de un conjunto de archivos ha comenzado, no hay recuperación; por lo tanto, la eliminación se convierte en un mejor esfuerzo una vez que se encuentra un error.

El archivo de estado de la instalación

El comando installp utiliza este archivo de estado para determinar el procesamiento adecuado. Si crea scripts de instalación, sus scripts deben producir un archivo de estado que tenga el formato correcto. Cada línea del archivo de estado tiene el formato:

El siguiente ejemplo de archivo de estado indica al comando installp que las instalaciones de los conjuntos de archivos tcp.client y tcp.server del paquete bos.net net se realizaron correctamente y que la instalación del conjunto de archivos nfs.client client no se realizó correctamente.

s bos.net.tcp.client
s bos.net.tcp.server
f bos.net.nfs.client

Para ver ejemplos de su uso, consulte el script de instalación por defecto, /usr/lib/instl/instal.