2011-11-24 18 views
10

He empaquetado mi aplicación en un paquete RPM, por ejemplo, myapp.rpm. Al instalar esta aplicación, me gustaría recibir algunas entradas del usuario (un ejemplo de entrada podría ser: el entorno donde se instalará la aplicación, "dev", "qa", "uat", "prod"). Según la entrada, la aplicación instalará los archivos apropiados. ¿Hay alguna forma de pasar parámetros al instalar la aplicación?RPM - Instale los parámetros de tiempo

P.S .: Una posible solución podría ser crear un paquete de RPM para cada entorno. Sin embargo, en nuestro escenario, esta no es una opción viable ya que tenemos alrededor de 20 entornos y no deseamos tener 20 paquetes diferentes para la misma aplicación.

Respuesta

16

En general, los paquetes de RPM no deberían requerir la interacción del usuario. Una y otra vez, los usuarios de RPM han declarado que el objetivo de diseño explícito de RPM es no tener instalaciones interactivas. Para los paquetes que necesitan algún tipo de entrada antes del primer uso, generalmente solicitas esta información en el primer uso, la pones en archivos de configuración con macros o algo así y le dices a tus usuarios que tendrán que configurar la aplicación antes de que sea utilizable .

Incluso pasar un parámetro de algún tipo cuenta como interacción del usuario final. Creo que lo que quieres es que tus scripts previos o de instalación detecten automáticamente el entorno de alguna manera, tal vez teniendo un archivo en algún lugar que puedan examinar. También señalaré que desde la perspectiva de un usuario de RPM, tener un paquete llamado * -qa.rpm es mucho más intuitivo que pasar un parámetro aleatorio.

Para su problema exacto, si está instalando contenido diferente, debería crear paquetes diferentes. Si tratas de hacer las cosas de manera diferente, terminarás peleando con el sistema RPM cada vez más.

No es difícil crear un sistema de compilación que pueda escupir más de 20 paquetes que en su mayoría son similares. Lo he hecho con un archivo de especificaciones de plantilla-ish y algunos scripts ejecutados por make que crearán varios archivos de especificación y generarán los RPM. Sin conocer los detalles, parece que incluso podría tener un paquete central en el que dependan los más de 20 paquetes de entorno, luego los paquetes específicos del entorno instalarán lo que sea específico de su entorno de destino.

+0

Gracias por la respuesta. En realidad, no requiero ninguna interacción del usuario como para pedirle al usuario que ingrese algo. Lo que estoy buscando es una forma de pasar un parámetro junto con el comando de instalación. Por ejemplo, ** rpm -i myapp.rpm -dev **. Hay una forma de llenar un archivo con el valor apropiado, de modo que el instalador de rpm pueda leerlo y recuperar el valor requerido. Estoy buscando algo más elegante que eso. –

+1

Lo contaría como interacción del usuario.Creo que lo que quieres es que tus scripts previos o de instalación detecten automáticamente el entorno de alguna manera, tal vez teniendo un archivo en algún lugar que puedan examinar. También señalaré que desde la perspectiva de un usuario de RPM, tener un paquete llamado * -qa.rpm es MUCHO más intuitivo que pasar un parámetro aleatorio. – kbyrd

+0

Agregué la información del comentario anterior en mi respuesta. – kbyrd

3

Puede utilizar la opción de reubicar, p.

rpm -i --relocate /env=/uat somepkg.rpm 

y tiene la secuencia de comandos mirar hacia arriba los datos variables de un archivo que se encuentra en el directorio "env"

0

Creo que esta es una pregunta muy válida, especialmente en cuanto se está moviendo en el desarrollo de aplicaciones reino. La configuración de la aplicación para diferentes sistemas de destino es su pan de cada día: debe configurarlo para Desarrollo, Prueba de integración, Prueba de aceptación, Producción, etc. Seguro que no creo que la solución sea crear un paquete separado para cada entorno. Básicamente debe ser el mismo código que se ejecuta en diferentes entornos. Sé que este requisito no es soportado por rpm. Pero lo que puede hacer para solucionar el problema es usar un archivo de configuración simple, que el script% pre sabe que debe buscar. El archivo de configuración podría ser un simple script de shell que, por ejemplo, establece variables de entorno, y luego los diferentes guiones e pre y post pueden usarlos.

Cuestiones relacionadas