Comparison Between Yum and RPM | Pros, Cons & Common Errors

The RPM Package Manager (RPM) is a powerful command-line driven package management system capable of installing, uninstalling, verifying, querying, and updating computer software packages. Each software package consists of an archive of files along with information about the package like its version, a description, and the like. There is also a library API, permitting advanced developers to manage such transactions from programming languages such as C or Python.

Yum is an automatic updater and package installer/remover for rpm systems. It automatically computes dependencies and figures out what things should occur to install packages. It makes it easier to maintain groups of machines without having to manually update each one using rpm. Yum has a plugin interface for adding simple features. Yum can also be used from other python programs via its module interface.

RPM Package Manager (RPM)

RPM is free software, released under the GNU GPL.

RPM is a core component of many Linux distributions, such as Red Hat Enterprise Linux, the Fedora Project, SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux, and many others.

It is also used in many other operating systems as well, and the RPM format is part of the Linux Standard Base.

Advantages of using RPM packages

A uniform, clean way for the user to install and remove programs with a single command.
Popularity: a lot of packages available, even though they often need recompilation to work in another distribution.
Non-interactive installation: makes it easy to automate installation.
Original source archive (e.g. .tar.gz, .tar.bz2) included: easy to verify(for security-critical packages like OpenSSH it is possible to check with md5sum that the sources were not modified).
Cryptographic verification with GPG and md5.
There are many popular interfaces, both command-line and graphical.

Disadvantages often cited include:

Often has backward-incompatible changes in package format.
Incomplete and outdated documentation.
if wrong cflags, the binary can be unstable/malfunctioning.
Specific steps to install/configure

List of commonly used RPM commands

rpm -ivh package-1.0.3.i386.rpm> Install RPM Package
rpm -e package-1.0.3.i386.rpm> Uninstall RPM Package
rpm -Uvh package-1.0.3.i386.rpm> Update RPM Package
rpm -Fvh package-1.0.3.i386.rpm> Freshen RPM Package
rpm -qa package-1.0.3.i386.rpm (or) rpm -qa | grep <package>> to review/list rpm packages installed
rpm -ql package-1.0.3.i386.rpm> show rpm using files
rpm -qf <file>> show file using rpms
rpm -rebuilddb> Rebuild RPM Database
rpm {-V|verify} [select-options] [verify-options] ? rpm verify
-v> verbose
-vv> very verbose
-h> display hash marks
aid> Linked(dependency) packages will install
force> forcefully installation
nodips> install rpm without dependency files

Common Issues and their fixes on this Topic :

1) < Error: failed dependencies>

Issuing rpm -i or rpm -U installs the software and you can start using it. RPM is very easy when it works. However, RPM can be a devil when it doesnt work. When you try to install an RPM package, RPM automatically checks its database for other files that the software being installed needs. If RPM cant find those files in its database, it stops installing the software and complains about failed dependencies.

When you get a dependency error, RPM spits out a list of files the program needs. Take a look at the list. The files in the list are probably ones you don’t have on your system or files you have but are wrong versions. When you get the dreaded dependency error, you’ll have to find the files RPM complains about, install or upgrade those files first, and then try to install the package you were installing in the first place.

If you know the needed files are there and RPM is just being stupid, you can ignore the dependencies. Use the nodeps option if you want to tell RPM not to check any dependencies before installing the package:

# rpm -i software-2.3.4.rpm nodeps

This forces RPM to ignore dependency errors and install software anyway, but note that if the needed files are missing anyway, the program won’t work well or won’t work at all. Use the nodeps option only when you know what you’re doing or when you’re bone-headed enough ;-)?

2) Sometimes a package is not removed cleanly.

Here is the situation, you try to install something and rpm says its already installed. You then try to remove it, and rpm says that is not installed. What can you do? rpm -ivh force package-1.0-5.i386.rpm

The force option is your solution.

3) Signature Keys

Fedora digitally signs all its RPM files, so its best to import their public encryption key beforehand so that the RPM installation program will be able to verify the validity of the RPM file. This can be done using the rpm command as seen in the next example. It is a good idea to import both the Red Hat and Fedora keys:

[root@bigboy tmp]# rpm import /usr/share/rhn/RPM-GPG-KEY

[root@bigboy tmp]# rpm import /usr/share/rhn/RPM-GPG-KEY-fedora

If you don’t install the keys you get a DSA signature warning that alerts you to the fact that the RPM file might be bogus:

[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm

warning: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: NOKEY, key ID

4f2a6fd2

Preparing #################################### [100%]

1:dhcp #################################### [100%]

It is always good to install the key files. If they are not there, the RPMs will install with only a warning message. If the RPMs digital signature doesn’t match that in the key file, the rpm installation program also alerts you and fails to install the RPM package at all:

[root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm

error: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: BAD, key ID

4f2a6fd2

error: dhcp-3.0pl2-6.16.i386.rpm cannot be installed

[root@bigboy tmp]#

Signatures are therefore useful because they help protect you against tampered and otherwise corrupted RPMs being installed.

YUM ( Yum Package Manager )

yum.conf – Configuration file for yum(8).

YUM Description:

Yum uses a configuration file at /etc/yum.conf.

Additional configuration files are also read from the directories set by the reposdir

option (default is /etc/yum.repos.d and /etc/yum/repos.d).

reposdir : A list of directories where yum should look for .repo files which define repositories to use. Default is /etc/yum.repos.d, /etc/yum/repos.d. Each file in this directory should contain one or more repository sections as documented in [repository] options below. These will be merged with the repositories defined in /etc/yum.conf to form the complete set of repositories that yum will use.

YUM Advantages:

Better mirror and failover support.

Supports multilib on dual 32-bit/64-bit systems (x86_64, PPC?, etc)?

(My opinion: YUM repositories are much easier to create on-demand.)?

YUM Disadvantages:

Wastes considerable bandwidth downloading header (.hdr) files.

Large updates take forever. (4 hours to update my laptop to rawhide)?

Isnt compatible with APT.
command is one of:* install package1 [package2] []

* update [package1] [package2] []

* check-update

* upgrade [package1] [package2] []

* remove | erase package1 [package2] []

* list []

* info []

* provides | whatprovides feature1 [feature2] []

* makecache

* groupinstall group1 [group2] []

* groupupdate group1 [group2] []

* grouplist [hidden]

* groupremove group1 [group2] []

* groupinfo group1 []

* search string1 [string2] []

* shell [filename]

* resolvedep dep1 [dep2] []

* localinstall rpmfile1 [rpmfile2] []

* localupdate rpmfile1 [rpmfile2] []

* deplist package1 [package2] []

Unless the help or -h option is given, one of the above commands must be present.

Repository configuration is honored in all operations.

Common Issues and their fixes on this Topic :

Error: Cannot open/read repomd.xml file for repository No more mirrors to try.

Suggestion: This error typically indicates that the mirrors listed in your /etc/yum.repos.d/ are out of date or temporarily unavailable. If the mirrors are in the process of syncing, this issue may correct itself after a short time. If not, you may need to update the list of mirrors Yum is using. Check with your operating system vendor for a more recent repo list.

Error: There was a problem importing one of the Python modules required to run yum. Cannot allocate memory

Suggestion: Python frequently runs into the memory limits set inside WHM and cPanel. You may be able to resolve this issue by increasing the per-process memory limit in the WHM Tweak Settings feature, or by running EasyApache from the command line to minimize its memory footprint.

Error: up2date error while loading shared libraries No such file or directory

Suggestion: This type of error sometimes indicates that the system software has been updated in small pieces rather than as frequent full updates. You may need to manually install the RPMs necessary to get up2date functioning again by locating them on RPMFind.net, your distributions mirrors, or your installation CDs. Often you can find help in locating the necessary RPMs by searching on your operating system vendors message boards for the exact text of the error message. Once the library issue is fixed, do a full system update.

Error: Traceback ImportError cannot open shared object file

Suggestion: This is similar to the up2date error just mentioned. Yum is unable to locate libraries it requires to function correctly. You may need to manually install the RPMs necessary to get Yum functioning again by locating them on RPMFind.net, your distributions mirrors, or your installation CDs. Often you can find help in locating the necessary RPMs by searching on your operating system vendors message boards for the exact text of the error message. Once the library issue is fixed, do a full system update.

Error: Traceback DatabaseError unable to open database file

Suggestion: This occasionally happens when Yum uses cached metadata that has been corrupted. yum clean dbcache may correct this issue.

Error: glibc-common is needed by package glibc-dummy-centos-4

Suggestion: This type of error message usually indicates that the glibc-dummy-[distro] -[release] package supplied with your Virtuozzo installation is not up to date with the latest changes provided by your Linux distribution. The glibc-dummy package is installed to save disk space by moving some data into the Virtuozzo template area. It should be safe to uninstall the glibc-dummy package, allowing Yum to upgrade glibc, but it would be better to have your VPS provider upgrade the glibc-dummy package for you. See the following for additional details: http://kb.swsoft.com/en/1010

Error: Missing Dependency is needed by package

Suggestion: This indicates that the mirrors known to your update system cannot fully fill the dependencies for the selected packages. This may be caused by an operating system library transition that is not yet complete or a delay in synchronization of the update mirrors. It may also indicate that a third-party mirror that was added to your mirror list has not kept up with package changes from your operating system vendor. If you have added third-party mirrors to your update system configuration, removing them may fix this problem. If that is not the case, wait for your operating system vendor to update their mirrors.

Error: Could not find the GPG Key necessary to validate pkg

Suggestion: Many distributions update the GNU Privacy Guard keys they use to sign packages and the package lists on an annual basis. Typically, the new GPG keys are sent out as an update before the old keys expire. If you perform updates infrequently, you may not receive the new keys by the time they are in use signing packages. Check with your operating system vendor to get a new copy of their GPG signing keys.

Error: file /etc/fonts/fonts.conf from install of fontconfig-2.2.3-13.el4 conflicts with file from package fontconfig-2.2.3-7 file /usr/share/man/man5/fonts-conf.5.gz from install of fontconfig-2.2.3-13.el4 conflicts with file from package fontconfig-2.2.3-7

Suggestion: Your OS is suffering from a known bug as outlined at http://bugs.centos.org/view.php?id=1024.

The solution is to fix the errant package, which is different for various systems. This is how it can be done with yum, rpm, or up2date (ALERT! Note: package names, versions, and archtypes may differ query your package manager as needed to determine what packages to actually manage!):

yum erase fontconfig-2.2.3-7.i386; yum erase fontconfig-2.2.3-7.x86_64

yum update; rpm -e fontconfig-2.2.3-7.i386;

rpm -e fontconfig-2.2.3-7.x86_64; up2date fontconfig

Error: No method to auto repair package system

Suggestion: This means that Cpanel::SysPkgss config check returned a failed status and does not have a way to try to fix what is detected. You will need to manually troubleshoot your OSs update system at this point.

Error: Checking GPG signatures Unknown signature /var/cache/apt/archives/some_package_here.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#3ab2ce5e)?

Suggestion: The system administrator needs to import the key used to sign the packages. See Could not find the GPG Key necessary to validate pkg for more information about that.

Error: Package system can not be repaired automatically

Suggestion: This means that Cpanel::SysPkgss config check returned a failed status and its attempt to auto fix the problem did not work. You will need to manually fix your OSs update system at this point.

If you require help, contact SupportPRO Server Admin