RPM - Install time parameters
Asked Answered
S

3

16

I have packaged my application into an RPM package, say, myapp.rpm. While installing this application, I would like to receive some inputs from the user (an example for input could be - environment where the app is getting installed - "dev", "qa", "uat", "prod"). Based on the input, the application will install the appropriate files. Is there a way to pass parameters while installing the application?

P.S.: A possible solution could be to create an RPM package for each environment. However, in our scenario, this is not a viable option since we have around 20 environments and we do not wish to have 20 different packages for the same application.

Saracen answered 24/11, 2011 at 14:30 Comment(0)
I
22

In general, RPM packages should not require user interaction. Time and time again, the RPM folks have stated that it is an explicit design goal of RPM to not have interactive installs. For packages that need some sort of input before first use, you typically ask for this information on first use, our you put it all in config files with macros or something and tell your users that they will have to configure the application before it is usable.

Even passing a parameter of some sort counts as end-user interaction. I think what you want is to have your pre or install scripts auto detect the environment somehow, maybe by having a file somewhere they can examine. I'll also point out that from an RPM user's perspective, having a package named *-qa.rpm is a lot more intuitive than passing some random parameter.

For your exact problem, if you are installing different content, you should create different packages. If you try to do things differently, you're going to end up fighting the RPM system more and more.

It isn't hard to create a build system that can spit out 20+ packages that are all mostly similar. I've done it with a template-ish spec file and some scripts run by make that will create the various spec files and build the RPMs. Without knowing the specifics, it sounds like you might even have a core package that all 20+ environment packages depend on, then the environment specific packages install whatever is specific to their target environment.

Irena answered 24/11, 2011 at 14:38 Comment(5)
Thanks for the reply. I actually do not require any user interaction as in prompting the user to enter something. What I'm looking for is a way to pass a parameter along with the install command. For e.g., rpm -i myapp.rpm -dev. There is a way to populate a file with the appropriate value, so that, the rpm installer can read it and retrieve the required value. I am looking for something more elegant than that.Saracen
I would count that as user interaction. I think what you want is to have your pre or install scripts auto detect the environment somehow, maybe by having a file somewhere they can examine. I'll also point out that from an RPM user's perspective, having a package named *-qa.rpm is a LOT more intuitive than passing some random parameter.Irena
I added the info from the comment above into my answer.Irena
Environment variables can be referenced in %pre and %post by escaping the $, like this: \$MY_SPECIAL_VARIABLE ...also, the variable \$RPM_INSTALL_PREFIX references the location that was passed in as --prefix $MY_CUSTOM_INSTALL_PATHAustralian
@Saracen You could use runtime RPM macros. The command would look like this: rpm -i myapp.rpm -D "mode dev" where "mode" is the name of the macro and "dev" or whatever string is its value it is expanded to in the scriplets.Chancroid
G
3

You could use the relocate option, e.g.

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

and have your script look up the variable data from a file located in the "env" directory

Germ answered 6/8, 2013 at 7:53 Comment(0)
D
0

I think this is a very valid question, specially as soon as you are moving into the application development realm. There he configuration of the application for different target systems is your daily bread: you need to configure for Development, Integration Test, Acceptance Test, Production etc. I sure don't think building a seperate package for each enviroment is the solution. Basically it should be the same code running in different enviroments. I know that this requirement is not supported by rpm. But what you can do as a work around is to use a simple config file, that the %pre script knows to look for. The config file could be a simple shell script that for example sets environment variables, and then the different und pre and post scripts can use those.

Dock answered 23/1, 2018 at 13:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.