There are many problems with this. Another is the fact that mock uses the host's yum to install in the chroot, which -> DB_VERSION_MISMATCH errors. See http://www.linux-archive.org/fedora-build-system/99017-corrupt-rpmdb-mock-chroot.html

I don't think this is a problem when f-r runs 'normally'. It then does (should do) the following steps:
- CheckBuild does a 'mock rebuild' which makes an implicit --init.
- CheckRpmlint runs rpmlint on the created packages.
- CheckRpmlintInstall installs the created packages into the chroot. It only has what's needed to build it in place.

It might fail if it has a runtime dependency on a BR which is not picked up automagically by rpm. But is this worth the effort of an extra --init?!

Unit tests is a completely different issue. Here this remark is very actual...

It might fail if it has a runtime dependency on a BR which is not picked up automagically by rpm.

That is exactly the problem.

Suppose there is package {{{foo}}} which should have {{{Requires(post): bar}}}, but it is missing.
Because the package has explicit {{{BuildRequires: bar}}}, the {{{bar}}} package is present during {{{foo}}} install time and {{{foo}}} installs correctly. But in normal environment {{{foo}}} installation would fail.

But is this worth the effort of an extra --init?!

In my opinion it is. Verifying dependencies is an important thing (at least for me).

You are probably right, especially when taking the scriptlets into account. Let's keep the bug open. It's not that it's hard to add a Mock.init(), it's just that I want to merge the current check-api branch before this - it provides a much better framework.

That branch, BTW, has a rudimentary script interface along the lines you proposed. Input welcome!

Fixed in f205fc9, and several commits up to de734f2. Thansk for bug report! Of course, feel free to reopen if needed.