I have encounter similar scenario, and like everyone else said, installing RPMs within a RPM is strongly discourage.
Anyway, the end result I use is a mixtures of 'requires', 'prereqs' and 'triggers' tags in the spec.
The 'prereqs' and 'requires' tag allows you to ensure package install order. Assuming you list out all your dependency then your RPM wouldn't be allow to install if other required RPMs didn't get install first.
The 'triggers' tag allows you to handle the case where a per-requisite package already installed.
I believe the 'prereqs' tag has been deprecated in newer version of RPM. If you would like to go that route then do a research and see what's the current approach.
On Mon, Dec 17, 2012 at 9:44 PM, Matthew Miller <email@example.com> wrote:
On Mon, Dec 17, 2012 at 09:39:19PM -0400, Fred White wrote:A "super rpm" is the wrong tool for the job, here. You _could_ do it, but
> a script and performs non-interactive installation (using expect). These
> are application specific RPMs and are currently not available in our
> rhn/spacewalk channels. These RPMs needs to be installed in a specific
> order and some of them also needs to be installed with nodeps (rpm -i
> --nodeps), since there are missing dependencies, and there are vendor
> instructions to do so.
you really shouldn't. The same goes for those vendor RPMs, which sound
As someone that has had to deal with several this kind of broken package, I can honestly say your life will be better if you just repackage their RPMs. Its ugly, but you can just extract their RPMs in your spec file.
Also, yell at your vendor. :) nicely of course (but it doesn't hurt to be a broken record). Making sure they know their process is broken and that there is a community of people can answer questions and help them make it better.
packaging mailing list