On Thu, Aug 23, 2007 at 08:42:04AM -0400, Jeff Johnson wrote: > Begin forwarded message: > > On Aug 23, 2007, at 7:19 AM, Patryk Zawadzki wrote: > > > >> On 8/23/07, Jakub Bogusz <[EMAIL PROTECTED]> wrote: > >>> On Thu, Aug 23, 2007 at 11:55:05AM +0200, Adam Gołębiowski wrote: > >>>> rpm --rebuilddb seems to fix this issue (I didn't try removing > >>>> __db*). > >>> The same for me, rm __db* was sufficient. > >> > >> Is it possible to remove it by a trigger? Triggers are run in the > >> middle of transaction and removing transaction state might have > >> unpredictable results. Maybe we need a macro that tells rpm to clean > >> after itself when upgrading: > >> > > > > Handling an error from an open db cache while changing the db > > implementation > > should not be done in db %post. For starters, you will find the > > dbenv always in use > > by rpm --upgrade. > > > > A trigger on db change could be added to the rpm package, but triggers > > are run in the middle of a transaction, with an open/live db cache, > > and that > > may cause a similar problem. > > > > Does poldek have a dbenv open between invocations of rpm --upgrade? > > Closing and reopening the rpmdb in poldek will be needed as well if > > you > > wish to invalidate the old cache in a dbenv while upgrading db. > > > > All that is known atm is that a "rm -f /var/lib/rpm/__db* on a > > likely quiescent > > dbenv "fixes" the symptoms.
In my case database wasn't open - rpm finished its work after db4.6 upgrade, and failed when I ran it again to upgrade some other package. I didn't use poldek during all those operations, just pure rpm invocations from bash. -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
