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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
