Test installation of RPM packages

Question

We are using rpm to deploy our web applications internally. The rpm installs the files, configures apache, cron, logging and so on.

I would like to build a test version of the rpm that installs in a different location with a different configuration for apache, cron and logging. It should be possible to install both the production and test rpm on the same machine.

With both rpms installed i would have something like

/opt/app/www/...
/opt/app-test/www/...
/etc/httpd/conf.d/app.conf
/etc/httpd/conf.d/app-test.conf
/etc/cron.d/app
/etc/cron.d/app-test
/etc/init.d/app
/etc/init.d/app-test

What would be a good way to achieve this?

• Copy the spec and rename everything to "test"?
• Create different subpackages for prod/test?
• Use rpm macros to alter the location and names in the spec?
• Use rpm --relocate?

Is there any existing rpm that tries to do this that i can look at?

Answer 1

In my spec files, I use the built-in macros and then, with a test account (not root) and a customized ~/.rpmmacros, I change the default prefix:

%_prefix %{_home}

Works fine.

You can even create a test rpm database:

$ rpmdb --initdb --dbpath /home/test/var/lib/rpm

and put this in your .rpmmacros:

%_dbpath /home/test/var/lib/rpm
%_rpmlock_path %{_dbpath}/__db.000

Answer 2

Even though you have a different solution, I decided to suggest another way to achieve this. Nothing wrong with virtualization though. Probably a better solution anyway since running a test environment on the same machine as production is not safe/secure I guess. That said...

I would probably use one spec file as a template and then this:

...
# somwwhere in the beginning of spec
%global testrel test

#rest of document
Source0: tarball-with-things%{?testrel}.tar.bz
...
%if ${?testrel:1}${!?testrel:0}
# this will execute only in test rpm
%endif
...

Note that especailly the %{?testrel} macro is the interesting thing. It enables you to update things simultaneously for both versions, but if you wish to keep something specific to one version or the other you still can. It also doesn't require any changes to the database, custom macros in ~/.rpmmacros (which would change depending on the system it's being built on)