On Thursday 01 of November 2007, Jeff Johnson wrote:
> On Nov 1, 2007, at 9:20 AM, Arkadiusz Miskiewicz wrote:
[...]
> > http://rpm5.org/cvs/tktview?tn=20
[...]
> Let's try to flesh out the problem with some details.
>
> rpm uses a dbenv for concurrent access, which adds
> persistent state to all accesses.
>
> rpm --root does several chroot(2) entries and exits, which
> forces trimming paths to rpmdb files after a chroot(2).
>
> The constraint on the solution is being able to support external,
> virgin, untouched, Berkeley DB for PLD.

I'm happy with internal BDB 4.6 (not 4.5). BDB is a nightmare, external BDB is 
a huge nightmare. I'm finally convinced that internal BDB is better for sake 
of everyone.

> So the current solution is to add a 10 line system open(2) wrapper
> that "knows" the chroot(2) path and strip the leading part of
> the path while rpm is within a chroot.
>
> All that works fine for a single process execution.
open wrapper fixed one issue for me.

>
> The issue that you are now reporting is harder because the
> persistent state spans this sequence:
>      rpm -ivh --root /root ....
>      chroot /root /bin/sh
>      rpm -qa
>
> So the paths that are saved persistently in the dbenv usually
> have the "/root" prefix, leading to failures. I'm almost certain
> that doing (in the chroot)
>      rm -f /var/lib/rpm/__db*
> "works".

Yes, that works but it's worse than using dbenv->remove() right? On IRC you 
said that remove() cannot be used due to some reason (?)

> Identifying if/when chroot(2) has been done (by another process)
> so that the validity of the paths persistently stored in the dbenv
> can be determined, and rpm can magically  Just Work will involve
> identifying if chroot(1) has been run. Not pretty.

Yeah, ugly.

> The other solution is hacking deep in system Berekeley DB to
> remove the persistently saved path. But that is at odds with
> the constraint of virgin/untouched external system Berkely DB.

Do you know where BDB stores that exactly? So I could play with reverting that 
part to 4.5 state.

> SOmethoing has to change to solve this problem.
>
> Meanwhile, can you confirm that indeed rpm "works" if
> you do
>      chroot /root /bin/sh
>      rm -f /var/lib/rpm/__db*


Worse than remove() right?


What about other root problem - http://rpm5.org/cvs/tktview?tn=21 ?

> 73 de Jeff

-- 
Arkadiusz Mi¶kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/