nate wrote: >> (There are even some things the simpler Red Hattish tools can do that >> the Debian ones can't, easily. rpm -qa, for one.) > > rpm -qa typically just lists all of the packages on the system, > the equivalent in debian is dpkg -l. Not really equivalent. The output is only sort of greppable. I frequently say something like "rpm -qa |grep -i mysql-", in that particular case because MySQL, Inc. keeps changing the way they name their RPMs, so I can never remember the exact package name to query on a given system when I'm looking at versions to decide whether to upgrade. If the truncated part of a long package name has what you want to grep, you won't find that package. And yes, I do remember RTFMing dpkg(1) and found that you can change the output format of dpkg -l to be more like rpm -qa, but I recall that the required command was way too long to type each time. Sure, I can wrap it in a script, but then I'm customizing all my systems to add commands to it that should have been in the base distro. Of such minor things are distro choices made. > A single unified source for patches, > security fixes etc. Yes, that's one of the things I take into account when deciding whether I want to use Ubuntu for a particular task: whether I need access to its huge repositories, or if I can get by with what CentOS provides, plus maybe a few third-party add-ons. Beyond a certain point, the choice becomes clear. This is not the case for most of my server-class machines, however. Basics like LAMP and Samba are all I really need in most cases. > Also the debian package databases are in plain text format, while > I'm sure it has happened I have never personally heard of someone > suffering from package database corruption on debian(assuming they > were running the 'stable' version). Such corruption reports seem > somewhat common in the RPM world with the binary databases. It's been many years since I had to run rpm --rebuilddb. It never did fail on me the few times I did have to run it, and the need to run it was *always* due to a kernel panic while manipulating the RPM DB, or proximate in time to it. Kernel panics always were rare on stable Linux distros even way back in the mid 90s, increasingly rare now, and RPM DB updates are rare in their own right. Rare squared. > Add to that the well tested ability to upgrade between minor > and major version numbers time and time again. I don't have to > hold my breath when I go from Debian 4.0 to 5.0, I can do it from > remote without ever losing connectivity, I don't even have to reboot > at the end I can continue running the older kernel if I want. I like that feature in principle, though I can't think I'd actually want it on any of my servers. On a desktop, sure, but never on a production server. I'd rather keep something creaking along on CentOS 3, running the server's tired old hardware into the ground, building a new CentOS 5 box to replace it in a swift cut-over, rather than upgrade that old box in place. I do like the way Ubuntu LTS works in this regard, though. It stays locked in the LTS jail, mostly as stable as CentOS with regard to updates, as long as you just do apt-get upgrade, but you can break out with a dist-upgrade to get onto the bleeding edge releases if you really want to. I still can't see myself ever doing that on a production server, but I guess it's nice to know I could. > I've never really been fond of yum myself, though it is much better > than what was there before(nothing, before rhn at least). The only thing I don't like about yum is how hard it is to kill an in-progress yum update, while it's still in the package downloading phase. Other than that, I greatly prefer it to the wordy apt-foo commands. > I currently maintain roughly 100 SRPMS And does your experience line up with mine, which is that the debian/* big-tree-of-assorted-files is a mess, nowhere near as clean as package-name.spec?