Bug 10333

I had installed rpm 2.5.3 and then installed rpm 3.0.2-5x, alongside, such
that both were reported as installed by rpm -qa; although, 3.0.2-5x was the
active version.  I wanted to back out 3.0.2-5x to experiment with or
research a particular item; therefore, I ran rpm -e against rpm-3.0.2-5x.

This caused rpm to become completely unusable, because the /usr/lib/rpm
directory and /bin/rpm executable were both deleted, meaning that the
installed 2.5.3 version couldn't be used.

/var/lib/rpm was apparently left untouched or intact, because the directory
and its contents were not deleted.

I was able to restore rpm from another RedHat Linux configuration on the
same PC, within an hour, spent determining what needed to be done and then
implementing the actions (copying over /usr/lib/rpm and /bin/rpm).

This leads to a couple of points:

1) Why would rpm remove /usr/lib/rpm and /bin/rpm when there's another
version of rpm installed?

2) Why would rpm remove /usr/lib/rpm and /bin/rpm, but not /var/lib/rpm
(although I'm glad this directory wasn't deleted or affected)?

How I think rpm should work when being applied for or to itself:

1) rpm should detect when it's being applied to itself, including based on
the operation being performed, and then immediately warn the user about
potentially undesirable effects, main and side, as well as to prompt the
user appropriately.

1.1) When install (-i) is the action and there's already an installed older
version of rpm, than or compared to the version being installed, rpm should
copy or backup the older version's directories and files.  This could be
done automatically, or through interaction with the user, while providing
the user with brief advice and explanations of why backups should be made (
the backups could be removed later by the user, perhaps through an
additional function in rpm, such as an option to remove backups of older
versions of rpm).

Anywa, for an example, when installing 3.0.2-5x and 2.5.3 (say) is also
installed, then copy 2.5.3's /usr/lib/rpm directory to
/usr/lib/rpm-2.5.3.backup, /bin/rpm to /bin/rpm-2.5.3.backup, ...

If the directories and files take up considerable disk space, then rpm
could tarball and gzip these, while leaving these in the same directories,
or prompting the user for a directory to store these backups in; or, rpm
could warn the user that they might want to do this, first, indicating the
potential undesirable effects if this isn't done, and letting the user make
the backups.  If rpm was to make these backups and disk space was lacking,
then rpm could warn the user of this and instruct the user to make these
backups, or prompt for another location to store the backups, for example.

1.2) When erasing an rpm package and there's another or older version also
currently installed, then restore the older version's backed up directories
and files, automatically, or at least prompt the user for what action to
take, or tell the user to restore the backups.

It would be better for rpm to automate making the backups, for rpm to be
able to keep track of this information, for greater reliability.

1.3) When update (-U) is the action, then update logically implies
replacing the current intalled version, with a newer version, which I
believe rpm currently does correctly.  However, even in this case, rpm
could automate backing up the prior version's directories and executable,
perhaps with an interactive user interface to allow the user to make this
control decision.

RPM is an important tool for configuration management; therefore, the
functionality should be thorough, as well as this bug or flaw removed.
Because of the importance of rpm, though, the functionality needs to be
thoroughly clean.

If I manage to download the sources for rpm, then I'll take a look at the
code to make appropriate changes, but you'll probably be able to have this
fix in, quickly, because the logic is simple.

This was done on a Red Hat Linux 5.1 system upraded to kernel 2.0.36-3.  I
don't know if that means that my system is now 5.2, because I also
installed all of the latest packages under the 5.1 updates, and am
currently working on downloading and installing of the packages under the
5.2 and 6.0 updates.  The original system, though, was 5.1, from 1997.