2011-11-24 10 views
10

Ho inserito la mia applicazione in un pacchetto RPM, ad esempio myapp.rpm. Durante l'installazione di questa applicazione, vorrei ricevere alcuni input dall'utente (un esempio potrebbe essere l'input - ambiente in cui l'app viene installata - "dev", "qa", "uat", "prod"). In base all'input, l'applicazione installerà i file appropriati. C'è un modo per passare i parametri durante l'installazione dell'applicazione?RPM - Parametri del tempo di installazione

P.S .: Una possibile soluzione potrebbe essere quella di creare un pacchetto RPM per ogni ambiente. Tuttavia, nel nostro scenario, questa non è un'opzione praticabile dato che abbiamo circa 20 ambienti e non vogliamo avere 20 pacchetti diversi per la stessa applicazione.

risposta

16

In generale, i pacchetti RPM non dovrebbero richiedere l'interazione dell'utente. Di volta in volta, gli utenti RPM hanno affermato che è un obiettivo di progettazione esplicito di RPM non avere installazioni interattive. Per i pacchetti che richiedono una sorta di input prima del primo utilizzo, in genere chiedi queste informazioni al primo utilizzo, le mettiamo tutto nei file di configurazione con macro o qualcosa di simile e comunichi ai tuoi utenti che dovranno configurare l'applicazione prima che sia utilizzabile .

Anche il passaggio di un parametro di qualche tipo conta come l'interazione dell'utente finale. Penso che quello che vuoi è avere il tuo pre o installare script in grado di rilevare l'ambiente in qualche modo, magari avendo un file da qualche parte che possono esaminare. Farò anche notare che dal punto di vista di un utente RPM, avere un pacchetto chiamato * -qa.rpm è molto più intuitivo rispetto al passaggio di un parametro casuale.

Per il tuo problema esatto, se stai installando contenuti diversi, devi creare diversi pacchetti. Se provi a fare le cose in modo diverso, finirai per combattere il sistema RPM sempre di più.

Non è difficile creare un sistema di build che possa sputare oltre 20 pacchetti che sono per lo più simili. L'ho fatto con un file spec di template-ish e alcuni script di make che creeranno i vari file spec e costruiranno gli RPM. Senza conoscere le specifiche, sembra che si possa persino avere un pacchetto principale su cui dipendono tutti i 20 o più pacchetti di ambiente, quindi i pacchetti specifici per l'ambiente installano ciò che è specifico per il loro ambiente di destinazione.

+0

Grazie per la risposta. In realtà non ho bisogno di alcuna interazione da parte dell'utente, come nel richiedere all'utente di inserire qualcosa. Quello che sto cercando è un modo per passare un parametro insieme al comando install. Ad esempio, ** rpm -i myapp.rpm -dev **. C'è un modo per popolare un file con il valore appropriato, in modo che l'installatore di rpm possa leggerlo e recuperare il valore richiesto. Sto cercando qualcosa di più elegante di quello. –

+1

Lo conterei come interazione dell'utente.Penso che quello che vuoi è avere il tuo pre o installare script in grado di rilevare l'ambiente in qualche modo, magari avendo un file da qualche parte che possono esaminare. Farò anche notare che dal punto di vista di un utente RPM, avere un pacchetto chiamato * -qa.rpm è molto più intuitivo rispetto al passaggio di un parametro casuale. – kbyrd

+0

Ho aggiunto le informazioni del commento sopra alla mia risposta. – kbyrd

3

È possibile utilizzare l'opzione di riposizionamento, ad es.

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

e hanno lo script cercare i dati variabili da un file si trova nella directory "env"

0

Penso che questa sia una domanda molto valida, specialmente non appena ci si sposta nello sviluppo applicazioni regno. Lì la configurazione dell'applicazione per diversi sistemi di destinazione è il tuo pane quotidiano: devi configurare per Sviluppo, Test di integrazione, Test di accettazione, Produzione ecc. Non credo che la creazione di un pacchetto separato per ogni ambiente sia la soluzione. Fondamentalmente dovrebbe essere lo stesso codice in esecuzione in diversi ambienti. So che questo requisito non è supportato da rpm. Ma quello che puoi fare come soluzione è usare un semplice file di configurazione, che lo% pre script conosca da cercare. Il file di configurazione potrebbe essere un semplice script di shell che, ad esempio, imposta le variabili di ambiente, quindi i diversi e gli script pre e post possono utilizzarli.