JavaScript is required to for searching.
Omitir Vínculos de navegación
Salir de la Vista de impresión
Guía del desarrollador para la creación de paquetes de aplicaciones     Oracle Solaris 10 1/13 Information Library (Español)
search filter icon
search icon

Información del documento

Prefacio

1.  Diseño de un paquete

2.  Creación de un paquete

3.  Mejora de las funciones de un paquete (tareas)

4.  Verificación y transferencia de un paquete

5.  Casos prácticos de creación de paquetes

6.  Técnicas avanzadas para la creación de paquetes

Especificación del directorio base

El archivo administrativo predeterminado

Familiarización con la incertidumbre

Uso del parámetro BASEDIR

Uso de directorios base paramétricos

Ejemplos: uso de directorios base paramétricos

El archivo pkginfo

El archivo pkgmap

Administración del directorio base

Posibilidad de reubicación

Recorrido de directorios base

Uso del parámetro BASEDIR

El archivo pkginfo

El archivo pkgmap

Ejemplo: secuencias de comandos de análisis que recorren un BASEDIR

La secuencia de comandos request

La secuencia de comandos checkinstall

Uso de rutas paramétricas relativas

El archivo pkginfo

El archivo pkgmap

Ejemplo: una secuencia de comandos request que recorra una ruta paramétrica relativa

Admisión de la reubicación en un entorno heterogéneo

Aproximación tradicional

Paquetes reubicables

Ejemplo: paquete reubicable tradicional

El archivo pkginfo

El archivo pkgmap

Paquetes absolutos

Ejemplo: paquete absoluto tradicional

El archivo pkgmap

Paquetes compuestos

Ejemplo: solución tradicional

El archivo pkginfo

El archivo pkgmap

Más allá de la tradición

Otra mirada a los paquetes compuestos

Cómo conseguir que los nombres de rutas absolutas tengan el aspecto de reubicables

Ejemplo: modificación de un archivo

Descripción

Implementación

Ejemplo

Ejemplo: creación de un nuevo archivo

Descripción

Implementación

Ejemplo

Ejemplo: un paquete compuesto

El archivo pkginfo

El archivo pkgmap

Creación de paquetes de instalación remota

Ejemplo: instalación en un sistema cliente

Ejemplo: instalación en un servidor o sistema autónomo

Ejemplo: montaje de sistemas de archivos compartidos

Paquetes de parches

La secuencia de comandos checkinstall

La secuencia de comandos preinstall

Secuencia de comandos de acción de clase

La secuencia de comandos postinstall

La secuencia de comandos patch_checkinstall

La secuencia de comandos patch_postinstall

Actualización de paquetes

La secuencia de comandos request

La secuencia de comandos postinstall

Creación de paquetes de archivo de clase

Estructura del directorio de paquetes de archivos

Palabras clave para admitir paquetes de archivo de clase

La utilidad faspac

Glosario

Índice

Posibilidad de reubicación

Al tiempo que puede seleccionar directorios base para diversos paquetes que se garantizan como exclusivos para una arquitectura y versión, esto conduce a niveles innecesarios de jerarquía de directorios. Por ejemplo, para un producto diseñado para procesadores basados en SPARC y x86, puede organizar los directorios base por procesador y versión tal como se muestra a continuación.

Directorio base
Versión y procesador
/opt/SUNWstuf/sparc/1.0
Versión 1.0, SPARC
/opt/SUNWstuf/sparc/1.2
Versión 1.2, SPARC
/opt/SUNWstuf/x86/1.0
Versión 1.0, x86

Es correcto y funciona, pero considera los nombres y los números como si significaran algo para el administrador. Una mejor aproximación es hacerlo automáticamente después de explicarlo al administrador y obtener un permiso.

Esto significa que puede hacer todo el trabajo en el paquete sin que necesite que el administrador lo haga manualmente. Puede asignar el directorio base de forma arbitraria y después establecer de forma transparente los vínculos al cliente adecuado en una secuencia de comandos postinstall. También puede usar el comando pkgadd para instalar el paquete total o parcialmente en los clientes de la secuencia de comandos postinstall. Incluso puede preguntar al administrador qué usuarios o clientes necesitan conocer este paquete y actualizar automáticamente las variables de entorno PATH y los archivos /etc. Esto es completamente aceptable siempre que, haga lo que haga el paquete tras la instalación, lo deshaga tras la eliminación.

Recorrido de directorios base

Puede beneficiarse de dos métodos para controlar el directorio base en el tiempo de la instalación. Lo primero es mejor para los nuevos paquetes que se instalarán sólo en Solaris 2.5 y versiones compatibles; ofrece información muy útil al administrador, admite varias arquitecturas y versiones instaladas, y requiere una cantidad mínima de trabajo específico. Cualquier paquete puede usar el segundo método y utiliza el control inherente de la secuencia de comandos request sobre los parámetros de generación para asegurar instalaciones correctas.

Uso del parámetro BASEDIR

La secuencia de comandos checkinstall puede seleccionar el directorio base apropiado en el tiempo de la instalación, lo que significa que el directorio base se puede situar en una posición muy baja del árbol de directorios. Este ejemplo aumenta el directorio base secuencialmente, lo que lleva a directorios con el formato /opt/SUNWstuf, /opt/SUNWstuf.1 y /opt/SUNWstuf.2. El administrador puede usar el comando pkginfo para determinar qué arquitectura y versión se instalan en cada directorio base.

Si el paquete SUNWstuf (que contiene un conjunto de utilidades que hacen el trabajo) usa este método, los archivos pkginfo y pkgmap tendrían este aspecto.

El archivo pkginfo
# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt/SUNWstuf
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none daemon
PSTAMP=hubert990707141632
El archivo pkgmap
: 1 1758
1 d none EZstuf 0775 root bin
1 f none EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none HRDstuf 0775 root bin
1 f none HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none /etc    ? ? ?
1 d none /etc/rc2.d ? ? ?
1 f daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865
1 i i.daemon 509 39560 752978103
1 i r.daemon 320 24573 742152591

Ejemplo: secuencias de comandos de análisis que recorren un BASEDIR

Suponga que la versión x86 de SUNWstuf ya está instalada en el servidor en /opt/SUNWstuf. Cuando el administrador use el comando pkgadd para instalar la versión SPARC, la secuencia de comandos request debe detectar la existencia de la versión x86 e interactuar con el administrador respecto a la instalación.


Nota - El directorio base se puede recorrer sin interacción del administrador en una secuencia de comandos checkinstall, pero si las operaciones arbitrarias como ésta ocurren con demasiada frecuencia, los administradores pierden confianza en el proceso.


Las secuencias de comandos request y checkinstall de un paquete que gestionan esta situación pueden tener este aspecto.

La secuencia de comandos request
# request script
for SUNWstuf to walk the BASEDIR parameter.
 
PATH=/usr/sadm/bin:${PATH}    # use admin utilities
 
GENMSG="The base directory $LOCAL_BASE already contains a \
different architecture or version of $PKG."
 
OLDMSG="If the option \"-a none\" was used, press the  \
key and enter an unused base directory when it is requested."
 
OLDPROMPT="Do you want to overwrite this version? "
 
OLDHELP="\"y\" will replace the installed package, \"n\" will \
stop the installation."
 
SUSPEND="Suspending installation at user request using error \
code 1."
 
MSG="This package could be installed at the unused base directory $WRKNG_BASE."
 
PROMPT="Do you want to use to the proposed base directory? "
 
HELP="A response of \"y\" will install to the proposed directory and continue,
\"n\" will request a different directory. If the option \"-a none\" was used,
press the  key and enter an unused base directory when it is requested."
 
DIRPROMPT="Select a preferred base directory ($WRKNG_BASE) "
 
DIRHELP="The package $PKG will be installed at the location entered."
 
NUBD_MSG="The base directory has changed. Be sure to update \
any applicable search paths with the actual location of the \
binaries which are at $WRKNG_BASE/EZstuf and $WRKNG_BASE/HRDstuf."
 
OldSolaris=""
Changed=""
Suffix="0"
 
#
# Determine if this product is actually installed in the working
# base directory.
#
Product_is_present () {
      if [ -d $WRKNG_BASE/EZstuf -o -d $WRKNG_BASE/HRDstuf ]; then
            return 1
      else
            return 0
      fi
}
 
if [ ${BASEDIR} ]; then
      # This may be an old version of Solaris. In the latest Solaris
      # CLIENT_BASEDIR won't be defined yet. In older version it is.
      if [ ${CLIENT_BASEDIR} ]; then
            LOCAL_BASE=$BASEDIR
            OldSolaris="true"
      else    # The base directory hasn't been processed yet
            LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR
fi
 
WRKNG_BASE=$LOCAL_BASE
 
    # See if the base directory is already in place and walk it if
    # possible
while [ -d ${WRKNG_BASE} -a Product_is_present ]; do
         # There is a conflict
         # Is this an update of the same arch & version?
         if [ ${UPDATE} ]; then
               exit 0    # It's out of our hands.
         else
               # So this is a different architecture or
               # version than what is already there.
               # Walk the base directory
               Suffix=`expr $Suffix + 1`
               WRKNG_BASE=$LOCAL_BASE.$Suffix
               Changed="true"
         fi
done
 
    # So now we can propose a base directory that isn't claimed by
    # any of our other versions.
if [ $Changed ]; then
         puttext "$GENMSG"
         if [ $OldSolaris ]; then
               puttext "$OLDMSG"
               result=`ckyorn -Q -d "a" -h "$OLDHELP" -p "$OLDPROMPT"`
               if [ $result="n" ]; then
                     puttext "$SUSPEND"
                     exit 1    # suspend installation
               else
                     exit 0
               fi
         else    # The latest functionality is available
               puttext "$MSG"
               result=`ckyorn -Q -d "a" -h "$HELP" -p "$PROMPT"`
               if [ $? -eq 3]; then
                     echo quitinstall >> $1
                     exit 0
               fi
 
               if [ $result="n" ]; then
                     WRKNG_BASE=`ckpath -ayw -d "$WRKNG_BASE" \
                     -h "$DIRHELP" -p "$DIRPROMPT"`
               else if [ $result="a" ]
                     exit 0
               fi
            fi
            echo "BASEDIR=$WRKNG_BASE" >> $1
            puttext "$NUBD_MSG"
      fi
fi
exit 0
La secuencia de comandos checkinstall
# checkinstall
script for SUNWstuf to politely suspend
 
grep quitinstall $1
if [ $? -eq 0 ]; then
    exit 3        # politely suspend installation
fi
 
exit 0

Esta aproximación no funcionaría muy bien si el directorio base fuera simplemente /opt. Este paquete debe indicar el BASEDIR de forma más precisa, puesto que /opt sería difícil de recorrer. De hecho, según el esquema de montaje, puede que no sea posible. El ejemplo recorre el directorio base mediante la creación de un directorio en /opt, lo cual no presenta problemas.

Este ejemplo usa las secuencias de comandos request y checkinstall, aunque las versiones de Oracle Solaris anteriores a la versión 2.5 no pueden ejecutar una secuencia de comandos checkinstall. La secuencia de comandos checkinstall de este ejemplo se usa para detener correctamente la instalación, en respuesta a un mensaje privado en forma de cadena quitinstall. ”. Si esta secuencia de comandos se ejecuta en la versión Solaris 2.3, la secuencia de comandos checkinstall se ignora y la secuencia de comandos request detiene la instalación con un mensaje de error.

Recuerde que antes de Solaris 2.5 y versiones compatibles, el parámetro BASEDIR es de sólo lectura y no se puede cambiar por la secuencia de comandos request. Por este motivo, si se detecta una versión antigua del sistema operativo SunOS (mediante la prueba de una variable de entorno CLIENT_BASEDIR), la secuencia de comandos request sólo tiene dos opciones: continuar o salir.

Uso de rutas paramétricas relativas

Si el producto de software puede instalarse en versiones anteriores del sistema operativo SunOS, la secuencia de comandos request debe hacer todo el trabajo necesario. Esta aproximación también se puede usar para manipular varios directorios. Si se necesitan directorios adicionales, se deben incluir en un único directorio base con el fin de ofrecer un producto de fácil administración. Si bien el parámetro BASEDIR no ofrece el nivel de granularidad disponible en la última versión de Oracle Solaris, el paquete todavía puede recorrer el directorio base mediante el uso de la secuencia de comandos request para manipular las rutas paramétricas. Éste es el aspecto que podrían tener los archivos pkginfo y pkgmap.

El archivo pkginfo
# pkginfo file
PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt
SUBBASE=SUNWstuf
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none daemon
PSTAMP=hubert990707141632
El archivo pkgmap
: 1 1758
1 d none $SUBBASE/EZstuf 0775 root bin
1 f none $SUBBASE/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none $SUBBASE/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none $SUBBASE/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none $SUBBASE/HRDstuf 0775 root bin
1 f none $SUBBASE/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none $SUBBASE/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none $SUBBASE/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none $SUBBASE/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none /etc    ? ? ?
1 d none /etc/rc2.d ? ? ?
1 f daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865
1 i i.daemon 509 39560 752978103
1 i r.daemon 320 24573 742152591

Este ejemplo no es perfecto. Un comando pkginfo -r devuelve /opt para la base de instalación, que es bastante ambigua. Muchos paquetes se encuentran en /opt, pero al menos se trata de un directorio con sentido. Al igual que el ejemplo anterior, el siguiente admite completamente diversas arquitecturas y versiones. La secuencia de comandos request se puede ajustar a las necesidades del paquete específico y resolver las dependencias aplicables.

Ejemplo: una secuencia de comandos request que recorra una ruta paramétrica relativa

# request script
for SUNWstuf to walk a parametric path
 
PATH=/usr/sadm/bin:${PATH}    # use admin utilities
 
MSG="The target directory $LOCAL_BASE already contains \
different architecture or version of $PKG. This package \
could be installed at the unused target directory $WRKNG_BASE."
 
PROMPT="Do you want to use to the proposed directory? "
 
HELP="A response of \"y\" will install to the proposed directory \
and continue, \"n\" will request a different directory. If \
the option \"-a none\" was used, press the <RETURN> key and \
enter an unused base directory when it is requested."
 
DIRPROMPT="Select a relative target directory under $BASEDIR/"
 
DIRHELP="The package $PKG will be installed at the location entered."
 
SUSPEND="Suspending installation at user request using error \
code 1."
 
NUBD_MSG="The location of this package is not the default. Be \
sure to update any applicable search paths with the actual \
location of the binaries which are at $WRKNG_BASE/EZstuf \
and $WRKNG_BASE/HRDstuf."
 
Changed=""
Suffix="0"
 
#
# Determine if this product is actually installed in the working
# base directory.
#
Product_is_present () {
      if [ -d $WRKNG_BASE/EZstuf -o -d $WRKNG_BASE/HRDstuf ]; then
            return 1
      else
            return 0
 
      fi
}
 
if [ ${BASEDIR} ]; then
      # This may be an old version of Solaris. In the latest Solaris
      # CLIENT_BASEDIR won't be defined yet. In older versions it is.
      if [ ${CLIENT_BASEDIR} ]; then
            LOCAL_BASE=$BASEDIR/$SUBBASE
      else    # The base directory hasn't been processed yet
            LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR/$SUBBASE
      fi
 
WRKNG_BASE=$LOCAL_BASE
 
# See if the base directory is already in place and walk it if
# possible
while [ -d ${WRKNG_BASE} -a Product_is_present ]; do
         # There is a conflict
         # Is this an update of the same arch & version?
         if [ ${UPDATE} ]; then
               exit 0    # It's out of our hands.
         else
               # So this is a different architecture or
               # version than what is already there.
               # Walk the base directory
               Suffix=`expr $Suffix + 1`
               WRKNG_BASE=$LOCAL_BASE.$Suffix
               Changed="true"
         fi
done
 
# So now we can propose a base directory that isn't claimed by
# any of our other versions.
if [ $Changed ]; then
         puttext "$MSG"
         result=`ckyorn -Q -d "a" -h "$HELP" -p "$PROMPT"`
         if [ $? -eq 3 ]; then
               puttext "$SUSPEND"
               exit 1
         fi
 
         if [ $result="n" ]; then
               WRKNG_BASE=`ckpath -lyw -d "$WRKNG_BASE" -h "$DIRHELP" \
               -p "$DIRPROMPT"`
 
            elif [ $result="a" ]; then
                   exit 0
            else
                   exit 1
            fi
            echo SUBBASE=$SUBBASE.$Suffix >> $1
            puttext "$NUBD_MSG"
      fi
fi
exit 0