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