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

[Nevyn]

On Jan 20, 2008 9:05 PM, Daniel Lawson <daniel at meta.net.nz> wrote:
>
> > 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... :)

I'm of the opinion that if I'm having to compile everything, it would
also be true that I have to know what it is I'm compiling. While in
the larger sense this is probably not too big an issue, chances are
I'm going to miss some vital kernel update or install Samba and find
that it wipes mount points or something. I'm only one person and I
would think it strange if there weren't say.... 500 odd packages on a
single system.

This is a hell of a burden and not one I'm willing to take on myself.
However, there's a solution. There are people out there who only
handle a couple of packages and contribute their efforts to a
distribution. So many hands make light work. I'm not going to presume
to know more about the kernel or samba or samba-client or whatever
else (imagine I've just listed out 500 odd packages) than the
maintainers. So long as my goals, which is to have a working system,
coincide with theirs and anyone else using the same packages, I see
little risk.