Which downloads mypkgname from <sys|int|uat|prod> yum repository with all of it's dependencies.

That obviously wouldn't always be possible, but it is achievable with only a little pain .

Use RPM for managing components of your System

RPM is not ideally suited to deploying java applications and all of it's dependencies, but it can work.

I've used it to package up an installation of activemq, with my application config and start/stop scripts.
This was then extended to have ant build it so we could eventually have cruise create rpm artifacts for a project which could eventually get automatically sent to a yum repository.

RPM is not that great but when you have to wrestle with RedHat AS atleast it gives us

• Dependency Management. Requires that mysql >= 5.0 must be installed.
• Hooks for pre/post install/uninstall Scripts. %postin let me create a os user if required, set appropriate permissions, create a database, db user, add tables and insert data.
• Ability to relocate the package on installation

Creating yum repositories sounds easy, but I haven't gotten to this yet.

What to do

1. Create your ~/.rpmmacros file
2. Create a specification file, don't forget it will has access to some of it's own types of variables that are defined in .rpmmacros file.
3. package up your application of choice in a mypkgname-version.tar.gz. This is your main input into rpm, Source0: in your spec file must exactly match this file
4. rpm -bb mypkgname.spec
5. check your pkg info with: rpm -qpi mypkgname-version-noarch.rpm and your list of files with rpm -qpl mypkgname-version-noarch.rpm.
6. sudo rpm -i mypkgname-version-noarch.rpm

Tips

1. Understand %files .I found it easier to build my own file.list, by using %files -f file.list. Defaulting attributes with %defattr(-,name,group) and %config to specify your config files are good to know about.
2. You don't have to use the root owned default database, you can specify your own with the --dbpath option
3. How can you tell if a package is being installed or updated?
   $1 of the scriplets (%pre, %postin...) contain the number of pkg's affected, so during an update you affect 2 pkgs, as it is an uninstall, followed by an install operation.
4. Scriptlets share the same environment, but that environment is special. We had issues running pre-packaged scripts that depended on env variables setup in .bashrc becaused it exited if it wasn't an interactive shell. ie. [ -z $PS1 ]
5. Keep multiple copies of ~/.rpmmacros files and replace the one you are interested in
6. If you are packaging ruby, python or java applications, then specify it as non architecture specific
7. Make it Relocatable if possible
8. Someone had a problem with BuildArch: noarch on FC4 x86-64, that noarch was not recognised as a valid architecture. We needed to add a line to some file in /var/lib??. Moral of the story is to try not to use debian based distro instead.

If you know almost nothing about RPM

• RPM can be used to manage src (c) or binary rpms.
• It works by unextracting a tar of the source/binary then building and executing scriptlets at the right moments.
• configuration files, identified by %config, like /etc/mypkgname are renamed when you erase a package to mypkgname.conf.rpmsave.
• Relocatable pkgs require all your packaged files to have the same prefix.

Thanks to co-conspirators Ajit George, Sam Jordan, Peter Klein, Robert Watkins.