On Mon, 2010-12-13 at 09:48 -0600, Clark Williams wrote:
> On Mon, 13 Dec 2010 10:33:52 -0500
> seth vidal <firstname.lastname@example.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
. I would recommend making sure you enforce locale=C if
you're going to use yum as a module to minimize unicodedecode
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.
buildsys mailing list