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. > > 73 de Jeff _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
