On Mon, 2010-12-13 at 09:48 -0600, Clark Williams wrote:
On Mon, 13 Dec 2010 10:33:52 -0500
seth vidal <skvidal(a)fedoraproject.org> 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