No! RPM won't cook your goose. (You'll have to do that yourself!) It will save any changes you've made, to a config file called file.rpmsave. Let's give it a try.

As system administrator, you want to make sure your new users have a rich environment the first time they log in. So you've come up with a really nifty .bashrc file that will be executed whenever they log in. Knowing that everyone will enjoy your wonderful .bashrc file, you place it in /etc/skel. That way, every time a new account is created, your .bashrc will be copied into the new user's login directory.

Not realizing that the .bashrc file you modified in /etc/skel is listed as a config file in a package called (strangely enough) etcskel, you decide to experiment with RPM using the etcskel package. First you try to install it:

# rpm -iv etcskel-1.0-100.i386.rpm

etcskel /etc/skel/.bashrc conflicts with file from etcskel-1.0-3

error: etcskel-1.0-100.i386.rpm cannot be installed

#

Hmmm. That didn't work. Wait a minute! You can add --replacefiles to the command and it should install just fine:

# rpm -iv --replacefiles etcskel-1.0-100.i386.rpm

Installing etcskel-1.0-100.i386.rpm

warning: /etc/skel/.bashrc saved as /etc/skel/.bashrc.rpmsave

#

Wait a minute. That's my customized .bashrc! Was it really saved? Let's see:

# ls -al /etc/skel/

total 8 -rwxr-xr-x 1 root root 186 Oct 12 1994 .Xclients

-rw-r--r-- 1 root root 1126 Aug 23 1995 .Xdefaults

-rw-r--r-- 1 root root 24 Jul 13 1994 .bash logout

-rw-r--r-- 1 root root 220 Aug 23 1995 .bash profile

-rw-r--r-- 1 root root 169 Jun 17 20:02 .bashrc

-rw-r--r-- 1 root root 159 Jun 17 20:46 .bashrc.rpmsave

drwxr-xr-x 2 root root 1024 May 13 13:18 .xfm

lrwxrwxrwx 1 root root 9 Jun 17 20:46 .xsession -> .Xclients

# cat /etc/skel/.bashrc.rpmsave

# .bashrc

# User specific aliases and functions

# Modified by the sysadmin

uptime

# Source global definitions

if [ -f /etc/bashrc ]; then

. /etc/bashrc

fi

#

Whew! You heave a sigh of relief and study the new .bashrc to see if the changes need to be integrated into your customized version.

Although --replacefiles can make today's difficult install easier, it can mean big headaches in the future. When the time comes for erasing the packages involved in a file conflict, bad things can happen. What bad things? Well, files can be deleted. Here's how, in three easy steps:

1. Two packages are installed. When the second package is installed, there is a conflict with a file installed by the first package. Therefore, the --replacefiles option is used to force RPM to replace the conflicting file with the one from the second package.
2. At some point in the future, the second package is erased.
3. The conflicting file is gone!

Let's look at an example. First, we install a new package. Next, we take a look at a file it installed, noting the size and creation date:

# rpm -iv cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

# ls -al /usr/bin/cdp

-rwxr-xr-x 1 root root 34460 Feb 25 14:27 /usr/bin/cdp

#

Next, we try to install a newer release of the same package. It fails:

# rpm -iv cdp-0.33-3.i386.rpm

Installing cdp-0.33-3.i386.rpm

/usr/bin/cdp conflicts with file from cdp-0.33-2

error: cdp-0.33-3.i386.rpm cannot be installed

#

So we use --replacefiles to convince the newer package to install. We note that the newer package installed a file on top of the file originally installed:

# rpm -iv --replacefiles cdp-0.33-3.i386.rpm

Installing cdp-0.33-3.i386.rpm

# ls -al /usr/bin/cdp

-rwxr-xr-x 1 root root 34444 Apr 24 22:37 /usr/bin/cdp

#

The original cdp file, 34,460 bytes long and dated February 25, has been replaced with a file with the same name but 34,444 bytes long and from April 24. The original file is long gone.

Next, we erased the package we just installed. Finally, we tried to find the file:

# rpm -e cdp-0.33-3

# ls -al /usr/bin/cdp

ls: /usr/bin/cdp: No such file or directory

#

One day it'll happen. You'll be installing a new package, when suddenly, the install bombs:

# rpm -i blather-7.9-1.i386.rpm

failed dependencies:

bother >= 3.1 is needed by blather-7.9-1

#

What happened? The problem is that the package you're installing requires another package to be installed in order for it to work properly. In our example, the blather package won't work properly unless the bother package (and more specifically, bother version 3.1 or later) is installed. Since our system doesn't have an appropriate version of bother installed at all, RPM aborted the installation of blather.

Now, 99 times out of 100, this is exactly the right thing for RPM to do. After all, if the package doesn't have everything it needs to work properly, why try to install it? Well, as with everything else in life, there are exceptions to the rule. And that is why there is a --nodeps option.

Adding the --nodeps options to an install command directs RPM to ignore any dependency-related problems and to complete the package installation. Going back to our earlier example, let's add the --nodeps option to the command line and see what happens:

# rpm -i --nodeps blather-7.9-1.i386.rpm

#

The package was installed without a peep. Whether it will work properly is another matter, but it is installed. In general, it's not a good idea to use --nodeps to get around dependency problems. The package builders included the dependency requirements for a reason, and it's best not to second-guess them.