yum/rpm vs. apt/dpkg (apt wins)

A comparison of Yum (RHEL 5.4) vs. Apt (ubuntu lucid)

Yum/RPM Pros:

'rpm -V' is very cool. It allows you to verify files that were installed from RPMs, which includes comparing owner, group, mode, md5, size, major/minor device numbers, symlink strings, and modification times to what was originally installed by the rpm. Use 'rpm -V -a' to verify all installed packages. Despite some wishlist bugs being filed, the closest dpkg comes is 'debsums', which only does hash comparisons.

Yum has $releasever and $basearch macros that can be put into yum repo configs. It would be great if Debian could do the same so $releasever would expand to 'lucid' or whatever distro you are running. This would make distributing standard apt sources.list files across an organisation running multiple versions much simpler.

Yum has 'localinstall', which allows you to install an rpm but satisfy its dependencies from the yum repo - neat! I believe the same is possible with apt, but it would look like:

dpkg -i single.deb; apt-get -f install

which is not exactly intuitive.

Yum/RPM Cons:

Yum has no command-line (tab) completion, which is super annoying.  I found I had to either do a search for my package first, or use commands like:

yum install http-*

which resulted in the installation of heaps of stuff I didn't need.

The decision to replace or not replace config files during package upgrades is left to the individual package maintainers. This is a serious bad idea. The two strategies are:

• 'rpmsave': install the new config, back the old one up as '.rpmsave'; and
  
• 'rpmnew': leave the old config in place and put the new one in as '.rpmnew'.
  

The first is a recipe for disaster, and means you absolutely must test every upgrade to see if it will bring down your production server. In contrast, if an apt update is going to change a config file that has been modified from the original packaged version, it pauses the update to let you decide how to proceed. You can view a diff, and decide to keep yours or install the package version. Whatever you decide, a copy of the old version is left in the directory. For apt, this behaviour is consistent for every package, ie. an apache package maintainer can't accidentally deface your website by replacing your highly-customised config with the default one.

When you uninstall a package with yum, the removal of rpms that were installed as dependencies is left up to the individual package post scripts. This means that you might install 10 dependencies, but only uninstall 8.

In contrast, Apt will uninstall each package it installed and leave configuration files in place (unless you specify --purge). Apt also has 'autoremove' (there is no yum equivalent), which allows you to remove any packages that are no longer needed. Packages that fall into this category are usually libraries that were dependencies for multiple applications, all of which have since been removed.

If you are running a 64-bit OS and point to a repository that has both 64-bit and 32-bit packages in it, apt is smart enough to realise that you probably want to install the 64-bit package. Not so with yum:

yum install openssl

might get you either the 32 or the 64 version. Worse still, running yum install openssl might try to install the 32-bit version over the top of the already installed 64-bit version.

The redhat community seems to be claiming this isn't a bug. OK, it is just a design flaw then, one that is going to start hurting a lot when the masses move to 64bit.

Yum package groups have long annoying names containing spaces that need to be escaped on the commandline. They also have 'optional' listed packages, but lack any way to install them (apart from copy paste). Apt has the same concept except it just uses meta-packages. The metapackages look and behave exactly the same as regular packages, which means you don't need a groupinstall command and they turn up in search results.

apt-get install --install-recommends

will get you all the recommended packages (you can also set this permanently in /etc/apt/apt.conf). In addition Debian has the concept of 'suggested' packages; you can also change apt.conf to install these automatically.

'yum search ftp' will turn up packages with an ftp URL (e.g. libsoup, which has nothing to do with ftp). Whoops! Apt does the right thing and searches the package title and descriptions, not the URL.

Yum search doesn't seem to handle multiple terms very well, it does an OR where it should do an AND.

Apt is way faster - the speed discrepancy is particularly noticeable when using search commands.