> I tried your suggestion and it works, however, since it implies > reinstalling all the packages from their RPM files, though in > database only, is no so different from reinstalling them completely. > If no standard solution is available, I was looking for a sort of > hack such as a query to manipulate the database directly. I guess > RPM development team should take this in consideration because it > allows a better portability of every RPM-based installation. Well, depending on any changes you've made and how big the install base is, it can be a lot smaller and quicker to perform. I think some would argue that having an easy direct way of manipulating the database would defeat some of the purpose of the security the RPM database helps provide. Take for instance this scenario: A hacker gets on my box and does a relocate of an important package (like procps) to a directory outside of everyone's path, and then drop installs a custom rpm with a name like procps- that provides similar files, but with malicious content. A rpm -qaV show the files all validating fine, and a rpm -q --whatprovides shows something that looks right... it isn't a pretty thought. Although... i'm not sure if procps is relocatable. But i think the point still stands. anyone else? -greg _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
