|
Sorry, but I am still stuck in my own version of RPM hell, and yes I have packaged RPM's. The problem: production servers for a client use RHEL 6.3 and are very slow to upgrade. Moreover, they don't have the subscription to RH's commercial repos, and instead host their own, which means that some packages are straight up missing. For development I use CentOS of a matching version. All works well until I go to deploy something to production and find out that a package I need is not available. The solution has been to (a) install packages from the CentOS repos (yup, old school download them off their site and then `rpm -i` them locally) or ask the client's IT to temporarily enable certain repos of later RHEL versions they have, so that I can install packages with lots of missing dependencies. The most recent fiasco with this involved ImageMagick and ImageMagick-dev not being there and depending on a crapton of libraries that were also missing. Now, I am not RPM-distro professional, I stick to Debian derivatives for the most part, but I have worked with them enough to know that unless you do things by RH's book, you are going to be in trouble, and even people whose full time jobs it is to maintain these production servers seem to have a really hard time figuring out how to get this right. P.S.: One solution I attempted was to create my own RPM repo that I could these missing packages from. This worked for some, until it landed me in a world of hurt where yum really wanted to install i386 versions of the packages instead of x64, even though (a) the server was x64 and (b) both versions of the package were available. This resulted in yum refusing to do anything because it saw conflicts. I have never had these types of problems with Debian based distros and a day of Googling for answers did not solve it. |
The whole point of getting your OS from RH is that RH has a book that you can do things by and be pretty well assured of the results. When they decided to no longer subscribe to that they really should have switched to a community managed Linux version.
I can't imagine the one time cost of moving their production servers to CentOS would be more than the continual update pains they're experiencing.