Fwd: db and rpm db

Jakub Bogusz qboosh at pld-linux.org
Thu Aug 23 17:07:10 CEST 2007


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 <qboosh at pld-linux.org> 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/


More information about the pld-devel-en mailing list