I tried getting rpm 3.0.6 and upgrading to rpm 4.0 on my RH 6.2 system and ended up completely iping my rpm database. I wanted to do this to install selected packages from my RH 7.0 CD so I could have them before doing a full upgrade. All of my important data is already LVMed off onto seperate partitions, and I was planning on doing a clean re-install for RH 7.0. If I hadn't, this would've been a lot more upsetting than it is. I realize this is my fault for doing something a bit goofy. I was fully aware of the rpm database change. I just somehow expected that the upgrade would handle this problem for me. And, of course, if I can't get LVM into the RH 7.0 kernel, I'm going to have a lot of problems. I can't install or upgrade packages anymore. Anyway, I wanted to register this complaint somewhere where someone would see it.
What does ls -al /var/lib/rpm say? If there is either a packages.rpm or Packages file there, your database is not "wiped", and, if not, rpm didn't do the rmove. There is no way for an install of the rpm package to handle the necessary "rpm --rebuilddb" as the database is locked at the time the %post scriptlet runs. Did you do the necessary "rpm --rebuilddb" when upgrading to rpm-4.0?
I did do rpm --rebuilddb, but it didn't do anything. I think the files were there, but now they are gone. I had already given up and tried installing a couple of the 7.0 packages I wanted to use because I wanted to use them. Perhaps it erased the old files then. I don't like this being resolved as 'notabug'. I entered it as an enhancement request, not a bug. I recognize that things acted as they were supposed to. I just think that what they are supposed to do is wrong. :-) Is there a way for a postinstall script to dump stuff to the terminal? If there are actions to perform that the user has to do because rpm can't, and rpm is run in interactive mode, it would be nice if rpm could tell the user what they were.
If you don't like "notabug", then bring that up with bugzilla. I have only a finite set of choices, and "not a bug" seems most appropriate to me. YMMV. rpm at the moment does only batch, unattended installs. Hence, no dialogue is possible. Even if dialogue were possible, there is no way that rpm can rebuilddb a locked database, and attempting that is a non-trivial amount of effort for little gain.
Right, I'm an not suggesting that it actually do the rebuilddb, just that it tell the user to do it after the install is finished. If it's strongly hardwired for batch installs, that'd be hard, but I don't think it is too badly. After all, it does handle the --hash option. And the interactive thing could be ditched if it discovered it was being invoked in a batch sort of way. Interactivity just to inform someone of something is only a small violation of the principle of not asking for configuration information during the install.
No input/output from scriptlets is Red Hat's packaging policy. The interaction with --hash is with rpm, not the package, doesn't really apply. Small, innocent, violations are quckly corrected here :-)
perhaps a mail sent through xmail to root might be useful here? first check if installed, then use that? or just a echo "rpm: run rpm --rebuilddb" >>/root/rpm.NEWS or something else in that way. I know of several packages during install, that needs post install steps (Tripwire anyone?) and itd be a good thing (tm) to add a notice with this to the root user.