Just an FYI, I figured out a solution.
In my BerkleyDB "emulation layer", I make sure we are inside of the
chroot before every sqlite call, and then return the state of the system
at the end of the call.
This seems to solve the problem, with only a bit of chroot overhead
occasionally.
Thanx,
Mark
Mark Hatle wrote:
I am working on using sqlite3 as a replacement database in RPM.
RPM has an option --root that will perform a chroot operation before
installing any files into the system.
This has presented itself as a problem. RPM opens the database, does
some validation ... performs the chroot ... and then attempts to write
to the database.
SQL returns back "unable to open database file". I tracked this down to
it attempting to open the journal based on the original path name and
not the chrooted path name.
Does anyone have any suggestions on how to solve this? Inform sqlite of
the root portion of the path? Temporarily disable the journal when the
chroot operation will be performed? Or some other mechanism?
Right now I am thinking of teaching sqlite about the concept of a root
path that can be stripped based on if the chroot has been performed or
not. But there may be a better way to do it then that.
Thank you!
--Mark
