I'd like to split a Tomcat installation into two different RPMs. One RPM would be a simple base installation, non-relocatable. The other would be a relocatable instance RPM that installs a separate CATALINA_HOME instance and depends on the base installation RPM. I know I could just name the instance RPMs based on their intended purpose but that seems really limiting and would result in multiple specially named RPMs. I'd rather have something like:

tomcat-base-$version-$dist-$arch.rpm
tomcat-instance-$version-$dist-$arch.rpm

I could then use puppet to install as many tomcat-instances as I need, each on different network interfaces.

The problem is that I can't seem to find any documentation on how this can be done, which leads me to believe that it can't, which would be a shame.

Or you could just create a single RPM with your custom configs/paths in it, which CAN be done. No different than packaging up a set of scripts/utilities for use on different systems.

Create your RPM with a dependency on the initial tomcat RPM package.

I'm not sure what you mean. That sounds like what I already mentioned and discounted. I'm trying to make it generic enough to handle arbitrarily adding new applications to a server. I already have a custom Tomcat RPM but it is for a single installation where CATALINA_HOME and CATALINA_BASE are the same directories.

I want to avoid something like:

tomcat-base-$version-$dist-$arch.rpm
tomcat-instance1-$version-$dist-$arch.rpm
tomcat-instance2-$version-$dist-$arch.rpm
tomcat-instance3-$version-$dist-$arch.rpm

I also want to avoid a custom RPM that contains two CATALINA_HOME directories because that's a hard coded limitation that's not much better than my existing RPM, what happens when we need to use the RPM on a server that needs three apps deployed all on different network interfaces?

A hacky way to do it would be to dynamically rebuild the RPM before every install passing in a variable that would determine how many times to duplicate the CATALINA_HOME environment, placing them all under a base path for instances. Naming them sequentially instance1, instance2, instanceN where N is the number passed into the build using --define. Not sure if that would work though.

Alternatively, I could just install the base package and handle all of the instances using puppet, downloading the Tomcat zip file and selectively extracting what I need from it for each instance required in the puppet code. That does sound way easier but I hate relying on downloaded files in my puppet code, especially from mirrors. I would also have to rely on proxies and that's really a pain and a source of lots of issues. Still, it does look like the puppet tomcat module will help a lot.