On Mon, 2010-12-13 at 09:48 -0600, Clark Williams wrote: > On Mon, 13 Dec 2010 10:33:52 -0500 > seth vidal <[email protected]> wrote: > > > On Sun, 2010-12-12 at 10:08 -0600, Clark Williams wrote: > > > Seth, > > > > > > I was scanning BZ's for mock this weekend (yes, I occasionally do > > > that) and saw the one (519258) where we fail due to the fact that we're > > > scanning the output of yum and not correctly handling being in the > > > German locale. I was wondering how much code would be involved in > > > importing yum modules and making direct calls into the yum API? > > > > > > A quick look at the code in py/mock/backend.py shows that we only call > > > yum with the following commands: > > > > > > install > > > update > > > resolvedep > > > groupinstall > > > > > > It's the resolvedep command that's failing, so it's possible that all > > > we really need to do is create a function that correctly resolves > > > dependencies without depending on any particular output. > > > > > > Thoughts? > > > > > > Once you get the yum object setup to talk to the chroot it should be > > easy to do the rest. The only question I have is if there is any selinux > > reason to not have mock do it b/c of the capabilities yum is afforded? > > > > -sv > > > > > > I'm not sure I parsed that question correctly. With the selinux plugin > enabled, mock sets up the chroot so that selinux is "disabled" inside > it, regardless of the state of selinux on the actual host running mock.
okay - if it is disabled that's fine - my main concern was making sure no labeling the yum executable has was going to impact things if mock was calling it directly. > The reason I am pondering directly accessing yum is that currently we > parse the output of the resolvedep command and string processing is > notoriously fragile once you leave the C locale. If we just make calls > into yum and get back objects representing the missing dependencies > (rather than parsing yum output as we do now) we side-step all the > locale issues. it gets rid of MOST locale issues - but it hands you more of the bizarro unicode issues :(. I would recommend making sure you enforce locale=C if you're going to use yum as a module to minimize unicodedecode tracebacks. The other thing that might be worth considering is using yum as an cli interface for the install/update calls but use the api for resolvedep. The only reason is resolvedep doesn't have much in the way of a callback so it is easy - the callback for install/update is a bit more involved if you want quasi-useful feedback in the mock log. -sv -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
