RPM Community Forums

Mailing List Message of <rpm-users>

Re: About the consistency of /var/lib/rpm/__db.00?

From: Marc MERLIN <marc_rpm@merlins.org>
Date: Tue 25 May 2010 - 20:38:36 CEST
Message-ID: <20100525183836.GN6064@merlins.org>
On Tue, May 25, 2010 at 01:57:52PM -0400, Jeff Johnson wrote:
> > It's not great, I need to wrap RPM with a shell script to do that reliably.
> > I'm not going to go into long details on our filesystem scanning/syncing
> > system but the fact that they show up on disk and they keep changing values
> > even if you do something as simple as rpm -q, is a fair problem here.
> Not true. I've already pointed you at code (and I believe its
> just setting a configuration macro) that will _AUTOMATICALLY
> remove __db* files at the end of every invocation.
> The code used to be there, just I've not looked for years ...
Right, but it's code that was removed from rpm and that I'd need to find and
re-integrate in, right?

> > and those were not needed in rpm 4.0.x and it worked fine without them.
> > Do newer rpms call bdb differently or did it just upgrade bdb to a version
> > that requires __db*?
> Bzzzzt! rpm-4.0.x went end-of-life like 8 years ago.
> Stop trolling FUD questions please ...
Haha, I wish I were. Now, I don't expect you to support it or feel
sympathetic, just that upgrading from it to a new one that does things that
cause problems that are actually impacting for us (it's more than one and
some are complicated, but just take my word for it), is not helping getting
off it :)

> > Understand I can't make that point to people when rpm 4.0.x worked great
> > without them. Unfortunate they are enough of a problem for us that people
> > are actually asking me to revert back to rpm 4.0 as a result of this.
> Nothing wrong with satisfying your customers at all.
Nope, although I would indeed like to migrate off ancient code too. Finding
a just middle is just a bit harder than I originally thought.

> So run as non-root always. RPM will not create __db* files if it
> cannot write to /var/lib/rpm.
Yes, that was in my other mail, probably an easy one.

> > If you have any idea if BDB can be made to stop since it was doing without
> > them before and that usage worked for us, and has for years, that'd be
> > great.
> Sure there's lots of ways, all of them quite b0rken.
> If you simply wish no locking whatsoever (and everything you ask
> indicates this) then set "private" and unset "use_environ_I_forget".
> Grep into /usr/lib/rpm/macros for the details. The token parser implementation

I'm looking into it now and seeing if I can find the magic option, thanks.

> is in in rpmdb/dbconfig.c, and there's _ALREADY_ more than enough configuration
> implemented in RPM (and going all the way back to rpm-4.0.x) for you to
> blow every single toe off of both your feet by disabling locks and
> disabling using an environment and enabling a global fcntl lock
> and automagically removing __db* files and even automagically
> running (*DB->verify) at end of every rpm invocation.

I didn't really find anything in macros, so I'm looking at dbconfig now,
thanks (I don't know much about BDB, so I'll try and see how it works).

> > If not, I guess, I'll just wrap rpm around an rm shell script.
> Or use a shell script, doing
> 	rm -f /var/lib/rpm/__db*
> in a shell script is quite KISS and easily achieved.

That's what I meant although the IO of even creating the unneeded DB files
is apparently unwanted :-/

"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
Received on Tue May 25 20:38:59 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.