Hide Forgot
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.
Lots of gibberish in that initial post. I'm definitely prepared to retract some of the gibberish ideas, however the general idea remains that rpm needs to or should be a little more reliable and user friendly, more or less along the lines initially stated. Some of the initial ideas are overblown or bad, but I think some are (little too verbose, but) appropriate. Anyway, because I see that this bug report hasn't been removed and appears to not have been considered, I am going to now up the priority level to where it perhaps should have been from the beginning. You may decide to lower it again, however I'll up it a notch or two, now. I wish it were possible to edit my initial post, though, to yank the excess.
Also, I have not gotten around to examining the source code, because I'm continuing to work on completing the upgrade to 5.2 and then 6.0, as well as being caught up with other priorities (in case this added comment is of any help).
For better or worse, rpm manages packages, not files. However, there's now a --repackage option in rpm-4.0.3 that puts the previously installed bits into a package before erasing. That should permit reinstalling the previously installed files more easily.