[nzlug] CentOS and the "joys" of rpm based systems

[Daniel Lawson]

> TBH, I wouldn't be using either in that environment, but doing all my package selection manually. Well, I actually go further than that and build from source for my production servers... of which only one is redhat.
>   


That's a bit gentoo-esque, isn't it? The idea that a package maintainer 
will add all the bells and whistles and make it impossible for you to 
not use them is a bit outdated.

Debian Woody (released 2002) used to have a bug where if you installed 
slapd, the openldap daemon package, it ended up pulling in X, due to a 
dependancy on an ODBC manager which had a GUI interface.  A bug, but 
I'll concede that it was caused by adding one of those "bells and 
whistles" which may have been better left unchecked, as I doubt many 
people use LDAP with an ODBC backend. However, I haven't hit any other 
troublesome unneeded or unwanted dependencies in Debian since then, and 
the same for Ubuntu. Or Redhat, for that matter. I'm sure it happens 
occasionally still, but it's not something I've hit in a problematic way 
for a long time.

Debian packagers go out of their way to modularise their packages in 
fact. You don't install "PHP" for example and get all the bells and 
whistles. Instead you install the base PHP package (cgi, modapache, cli, 
or any combination of the above), and then whichever modules you want as 
separate packages.  It's definitely false to claim that package managers 
will put extra stuff in there deliberately. Gentoo manages this with USE 
flags, FreeBSD via ports, and RedHat has a similar method to Debian.

> In a production environment, I don't trust anyone but myself to decide what software to load on my servers - especially not third party packagers who tend to add all possible bells and whistles. 
>   


In a production environment, I definitely don't trust whoever is doing 
the maintenance of a machine to keep up to date with not only upstream 
bug/security releases, but also to actively backport security fixes to a 
stable version that it turns out you can't move from.  I'm doing the 
maintenance today, but I might not be tommorrow, and I have some level 
of duty to make sure the systems I implement will work without needing 
my constant care and attention. I'm not saying I ignore these aspects, 
just that it's a far more efficient use of my time to not reinvent the 
wheel.


It's also worth noting that merely using apt, or yum, or whatever, 
doesn't mean you don't get a say in what's installed. I'm not as 
familiar with yum, but there are plenty of ways to circumvent unwanted 
and unneeded bad "dependancies" with apt. The simplest way is to create 
a dummy package which provides the dependancy, and will therefore keep 
your package management system happy. Debian even provides 
infrastructure for this with the equivs package


When it gets down to it, I don't have time to hand fetch packages from 
repositories, tracking through their dependancy tree. I did that with 
older versions of redhat, and I now manage far too many servers to make 
it palatable. I also don't have time to second guess the guys who do 
package management and bug tracking/patching/backporting *all the time*.

I'd much rather spend my workday doing new work, trying to clear out my 
blogroll, or hell, even replying to NZLUG emails... :)