On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote: > The way I *think* it used to work was that mock-helper would set the > LD_PRELOAD and then exec() the required program (rpm, yum, whatever). > When it came to running yum, it didn't exec() yum directly, it exec()-ed > mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD > from the environment (the libselinux-mock already being in place from > the exec() that called it). The result of this was that child processes > of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the > fake libselinux without the LD_PRELOAD being visible. > > The more integrated architecture of mock now may make this sort of hack > quite difficult to implement.
s/difficult/easy/g; It should be extremely easy to do this, *if* it is necessary. We just need to set/unset the variable as necessary around all calls to external programs. Like this: os.environ['LD_PRELOAD'] = "..."; or del(os.environ["LD_PRELOAD"]); Luckily, we have *one* entry point to call all external programs, atm, which is mock.util.do(). We just need to decide before each external call if we need to set the variable or not. We also have *one* wrapper for running yum, which then calls down to mock.util.do(). If necessary, we could easily set/unset this variable in that call and insulate all other callers from this knowledge. All-in-all, if we can come up with a test case for why we would still need the preload, I could quite easily add this functionality back. So far, though, I'm not seeing a lot of evidence of what is broken, and I'm the sort that likes to see the broken pieces before I implement the fix. -- Michael -- Fedora-buildsys-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
