We're using HP DataProtector for our backup environment. The installation method leaves something to be desired, and we're attempting to automate it in such a way that it makes our Unix admins cringe less often. We're a SLES/OpenSUSE shop, so we're attempting to make up a YUM repository with the DP patches.I can make the repo just fine, it's just that the patch RPMs aren't configured right. The 'Revision' field in the RPM is not set correctly, they're all 1 even though the master RPM I pulled them out of is correctly incrementing.I would really like to be able to rebuild these RPMs with the correct Revision, as that would allow the normal update process to deal with these patches instead of the strange way HP wants to handle these. The strange way HP wants to handle these requires:Setting up an Installation Server with all of the software. No problem.Allowing root to ssh into client stations to install software that affects xinitd configWhich in turn requires a passwordless SSH public-key to be placed on all target machines so the install process can remote in w/o prompting.Before any deployments can be made, each client must be manually SSHed to by root on the repo server in order to populate known_hostsSince we don't allow root logins via SSH, every time we get a patch we have to touch each server's sshd_config to allow them temporarily. We've also proven  that after the initial install, subsequent patches can just be installed via rpm just peachy. So, we'd like to get that into a YUM repo if at all possible.
Repackaging RPMs
packaging;rpm;patch
Rather than re-package the existing RPM, inspired by HP I packaged it in an additional RPM. The new RPM is very simple in that it just has the single patch-RPM inside it, and invokes the rpm command to install it.