[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: gtk2 update on fc8 SOLVED!



Gilboa Davara wrote:
On Fri, 2008-01-25 at 13:47 +0800, Ed Greshko wrote:
Gilboa Davara wrote:
On Fri, 2008-01-25 at 13:15 +0800, Ed Greshko wrote:
Gilboa Davara wrote:
The GTK2 update might have contained a number of security updates; while
having a broken update will not cause any visible corruption, it may
leave the machine open for an attack.
Do you think running "rpm -V" on the gtk2 package would be a good idea first?
It should... as long as RPM DB is not corrupted.
Being paranoid, I rather reinstall the RPM and reduce the risk.
I think I have been lucky over the years...knock on wood. I've not found myself in a situation where an "rpm -Uvh" or "rpm -ivh" has hung or my rpm db became corrupted. (I think I had a problem way back in the Red Hat 7, not Fedora days....) So, I've never seen the need to use --force.

So, one last question(s), if the rpm db is corrupted isn't it likely that "rpm -V" would fail? Would a corrupted db cause other packages to fail verification. And finally, what are the chances that you'd have an incorrectly installed rpm and an rpm db that was corrupted in such a manner that the verification would succeed?

As I said, I never have run into these kinds of problems....so these questions have only just now popped into my head.

Thanks...


P.S. Don't forget about %post.
If say, a SELinux RPM transaction hangs, the rpm -V test results will be
mostly irrelevant, as a lot of work is being done in %post.
The only way to insure a fully-working installation is RPM -Uvh --force.

- Gilboa


When a package being installed using pup, (compiz-gnome) and the transaction hung on that rpm, I ended up quitting pup after the fan kicked in. After the problem I decided to try the --force option to clean up rather than the --replacepkgs and replacefiles options to rpm. What happened is with using --force I still had the bogus previous released packages database entry left in the rpm database. Using the other two options to rpm instead and the bogus not cleaned up entry because of the one package that effected the plus 40 package transaction was cleaned up as well.
After my experience, I don't trust --force over individual options.
Just my recent experience since --force by description did not sound as deadly as first assumed. Actually using it was a different experience.

Just my experience,
Jim


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]