Comment 4 for bug 635869

Yes, the db itself is arch-independent, only the environment (the __db.* files) is not.

As to why rpm leaves the environment around after use is somewhat more complicated issue (hasn't been my decision, this is just the way it's "always" been):

Not removing is ok and almost recommended according to BDB documentation: "Calling DB_ENV->remove should not be necessary for most applications because the Berkeley DB environment is cleaned up as part of normal database recovery procedures." I suppose there's non-zero cost to setting up the environment instead of just using an existing one, but haven't measured it.

Perhaps the more practical issue is that the code to figure out correct flags on opening the rpmdb is racy when the environment is not present. So leaving the environment around swipes this issue under the carpet much of the time.

I actually do think that removing the environment after use is the sanest way to deal with bug 455836 and its variants, it just requires the races to be eliminated, either by a) rewriting the somewhat twisty opening logic in a non-racy way b) serializing the open+close paths with an extra lock. b) is probably the easier short-term fix.

In any case, I still think calling rpmquery instead of using librpm API would be beneficial for GDB: the same code would work on practically any rpm version you can dig up, it'd be one less library dependency and it would avoid the biarch issue.