<mild rant..> RPM hell on a server? If you're running a business on a box you shouldn't be installing any rpm's that didn't come from the distro provider, and, ergo, rpm hell should not occur.
We have 8 RedHat servers at work with a corporate RHN subscription, they operate as File&Print, Firewall, Web server, intranet, and appliances. I've never had an RPM conflict on them, because the only thing that isn't RedHat supplied is the UPS daemon from APC. RPM Hell generally comes from trying to install RPM's from someone apart from the distro provider, or installing Patches out of order. In either case you've lost the plot if you're doing this on your server that users depend on. In terms of business continuity and disaster recovery positions RedHat is probably the best offering at the business end of the OSS/Linux market. That's why they are so big, companies look at their model and can see how they will get on when things go wrong. I look at Debian and Gentoo and shiver about the time it might take to re-build a complex server built on either of them. No business in it's right mind would allow an IT supplier to install a server which required detailed Linux knowledge to install, whereas you can write a one page description of how to build a RedHat server, add the packages needed, run up2date and restore a backup. </mild rant> Chris Goes back to sleep... On Wed, 2003-09-03 at 11:38, Nick Rout wrote: > mechanism. (you did touch on this later in your email). rpm hell is to > be avoided. for that reason my next server (for which I already have the
