I'm writing some RPMs which install YUM repo configuration files for various internal YUM repos, same structure and concept as the EPEL repo RPMs.
We will have multiple environments with equivalent repos, so we use yum priorities plugin to insure environment repos earlier in the deployment sequence (i.e. QA) have priority over those which come later (i.e. Production). We're also replicating the CentOS versions we use on an internal mirror. We have all of this working, including the publication of these repo configuration RPMs, but have one special case remaining where I'd like some advice on the best way to handle a design issue.
And that is: The CentOS base repo configuration file /etc/yum.repos.d/CentOS-Base.repo is owned by the centos-release RPM, so I can't overwrite this in my own RPM without replacing this system RPM, which I don't want to do. But, I need to make some changes to this file so that it works with the design described above. In each repo section,
I need to change these lines:
To these lines:
I'm currently creating an RPM which installs /etc/yum.repos.d/CentOS-Base-pr.repo, then in the %post it renames the existing CentOS-Base.repo to CentOS-Base.repo.orig, then renames the new CentOS-Base-pr.repo to CentOS-Base.repo. In the %postun, it reverses this to restore the original file. I feel this works, but it's a bit of a kludge.
What I'd like to do instead, is install no files, but run a sed script to make these changes to the original CentOS-Base.repo file in the %post, and another sed script to reverse the changes in the %postun. This allows me to handle the install/uninstall of all of our custom repos in the same way, with a consistent result for both existing and new repos.
What I don't know is - is this a valid or recommended approach when you're trying to do this type of configuration "tweaks" to existing files installed by other RPMs?
Before I get answers to this effect, we're using Chef for most post RPM configuration similar to this, but don't want to use that in this case, as we don't want to have a special case on the repo config in just this one instance, and we're trying to use RPMs to encapsulate "heavy-lifting" install/upgrade logic inside of RPMs elsewhere. We want our own software to behave like other open source software in that it can install and run without a dependency on Chef for basic installation, and Chef is only used for customization (i.e. how Chef configures nginx or tomcat).
Thanks in advance for any advice...