[PATCH] Re: mock feature requests

seth vidal skvidal at phy.duke.edu
Tue Jun 21 05:29:07 UTC 2005


On Mon, 2005-06-20 at 14:17 -0400, Dan Williams wrote:
> On Mon, 2005-06-20 at 13:26 -0400, Dan Williams wrote:
> > 1) Ability to pass $statedir from mock's command line.  Since the
> > process calling mock has no clue where the buildroot actually is
> > (without parsing the *.cfg file for the buildroot, see issues with that
> > below), the builder needs to be able to specify where mock writes its
> > state so that the builder can read that state.  We talked about adding a
> > "--statedir" parameter to mock.
> 
> The attached patch negates this issue, since the process calling mock
> can determine the buildroot directory from the first line of mock's
> stdout.

relying on screenscraping results seems like a bad idea. We'd be better
off writing out config information to the resultdir or the statedir and
having both of those be specifiable on the cli.

In fact - writint out config info variables to the resultdir might make
a lot of sense as it will give us more info on the buildroot
environment.



> The attached patch fixes this by adding a "--buildroot-suffix" switch
> that allows the caller to pass an string (allowed characters are
> _-[a-z][A-Z][0-9]) which is appended to the buildroots directory.
> Default is nothing, and the new functionality is only triggered by usage
> of this switch.

<nod> but does the suggestion before deal with that?

> The patch also fixes a traceback where 'my' is undefined if the call to
> Root() fails for any reason (usually, in the cleaning stage).
> my.close() was unconditionally called no matter whether or not 'my' had
> already been defined.
> 
> Seth: if the patch looks OK and the solutions are acceptable, I can
> commit when you give the ack.

I guess I'm thinking writing out config information into the resultdir
immediately when mock starts up would be safer in some ways. Does that
sound reasonable to you?


-sv





More information about the Fedora-buildsys-list mailing list