FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 12-13-2010, 02:33 PM
seth vidal
 
Default time to implement a 'yum' object in mock?

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


--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-13-2010, 02:59 PM
seth vidal
 
Default time to implement a 'yum' object in mock?

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


--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 
Old 12-14-2010, 09:58 PM
Ville Skyttä
 
Default time to implement a 'yum' object in mock?

On Monday 13 December 2010, seth vidal wrote:
> On Mon, 2010-12-13 at 09:48 -0600, Clark Williams wrote:
> > 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.

Note that current mock git (and 1.1.7 I gather) only use resolvedep for the
more_buildreqs stuff from configs, which I guess is a quite rarely used
feature. Regular build dependencies are now installed with yum-builddep.
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
 

Thread Tools




All times are GMT. The time now is 03:12 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org