Warren Young wrote:
> I think much of the hype about how great the Debian packaging system is
> came from the days before they adopted yum, so Debian fans could point
> to apt-get and say "Isn't it great to be able to install packages from
> the net directly from the command line?" Sure, once upon a time it was,
> but today, the main distinction I draw between the two sets of tools is
> that the Debian tools are more complex with no compensating benefit.
> (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.
I think much of the "hype" isn't really hype and mistakenly compares
package formats deb vs rpm, and package managers apt-get/aptitude
/dselect(shuder) vs yum.
Building from source is pretty easy assuming you have src entries in
apt's configuration:
apt-get build-dep <package name> <- installs all dependencies required
for building
apt-get source -b <package name> <- downloads and extracts source code
and compiles it
It's more about the repositories themselves, the QA behind them,
the integration of packages. A single unified source for patches,
security fixes etc.
>From Debian 5.0 (lenny):
Total package names: 29647 (1186k)
Normal packages: 22400
Pure virtual packages: 319
Single virtual packages: 2154
Mixed virtual packages: 209
Missing: 4565
No need to go to 3rd party repositories, no need to worry about
overrides, worrying about a 3rd party repo overwriting another
package on the system, very wide selection of well tested packages
(and yes I stick to Debian stable, haven't needed to run 'testing'
since about 2002).
At least package counts Debian has more than 10x more packages
than CentOS 5.2. My desktop at home has nearly 1900 packages
installed.
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.
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.
Perhaps things have changed recently but last I heard there was
no supported upgrade path to go from RHEL 4 to 5 (I'm sure it's
possible but I don't believe it's supported). There are folks
out there that have seamlessly upgraded debian from back in the
2.x days all the way to current, more than a decade of upgrades
on one box. I have only gone a couple major revisions before I
end up retiring the hardware and starting fresh myself.
Since Ubuntu builds on Debian a similar number of packages are
available for it though they don't go through as much QA in the
universe and multiverse repositories, but do in many cases inherit
the QA done by the Debian team.
I've never really been fond of yum myself, though it is much better
than what was there before(nothing, before rhn at least).
I've been using RHEL/CentOS for about 6 years, Debian for about 11
years. I do prefer RHEL/CentOS for my "work" systems since I configure
things on a larger scale and that requires quite a bit of customization,
and I use Debian for all of my personal systems. These days I'm much
more familiar with the internals of RHEL/CentOS than I am Debian
anymore.
I currently maintain roughly 100 SRPMS(results in roughly 465 binary
RPMs) for my production environment (compile for CentOS 4/5 32,64 and
noarch) which are distributed to the systems using cfengine depending
on what the systems need.
Don't get me wrong I really do like CentOS it has it's purpose, I
just wanted to try to clarify what I view to be a misconception among
folks who champion debs over RPM, it's much less due to the format of
the packages themselves, or the package manager itself.
If you feel comfortable going down paths that offer less support
such as using 3rd party repos, performing non standard steps to
do system upgrades etc then that's great. These days I prefer less
wildcards in my life so I don't venture beyond the unsupported unless
I really need to(folks may be able to determine this by my ratio
of questions to (attempted) answers on this list).
happy trails
nate